PEP 668（Pythonコーディング規約）を翻訳した結果についてまとめました。
ニュース記事(英文と機械翻訳)
PEP 668 – Marking Python base environments as “externally managed”
PEP 668 – Python ベース環境を「外部管理」としてマークする
Attention
This PEP is a historical document. The up-to-date, canonical spec, Externally Managed Environments, is maintained on the PyPA specs page.
See the PyPA specification update process for how to propose changes.
注意
この PEP は歴史的な文書です。最新の標準仕様である外部管理環境は、PyPA 仕様ページで管理されています。
変更を提案する方法については、PyPA 仕様の更新プロセスを参照してください。
Abstract(概要)
A long-standing practical problem for Python users has been conflicts between OS package managers and Python-specific package management tools like pip.
Python ユーザーにとって長年の実際的な問題は、OS パッケージ マネージャーと pip などの Python 固有のパッケージ管理ツールとの間の競合です。
These conflicts include both Python-level API incompatibilities and conflicts over file ownership.
これらの競合には、Python レベルの API の非互換性とファイル所有権の競合の両方が含まれます。
Historically, Python-specific package management tools have defaulted to installing packages into an implicit global context.
歴史的に、Python 固有のパッケージ管理ツールは、暗黙的なグローバル コンテキストにパッケージをインストールすることをデフォルトとしていました。
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.
仮想環境の標準化と普及により、ほとんどの (ただしすべてではない) ユース ケースでは、Python 固有のパッケージ管理ツールを仮想環境内でのみ使用する方がよいソリューションです。
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.
この PEP では、パッケージ インストール コンテキストが OS パッケージ マネージャーなどのPython 外部の手段によって管理されているpipのようなツールと連携しているPythonインストールのメカニズムを提案します。
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.
デフォルトでは、Python 固有のパッケージ管理ツールはインタープリターのグローバル コンテキストにパッケージをインストールまたは削除せず、代わりにエンド ユーザーに仮想環境の使用を案内する必要があることを指定します。
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.
また、sysconfig スキームの解釈を標準化することで、Python 固有のパッケージ マネージャーがインタープリター全体のコンテキストでパッケージをインストールしようとする場合に、外部パッケージ マネージャーとの競合を回避し、外部パッケージ マネージャーによって出荷されたソフトウェアを破損するリスクを軽減する方法でインストールできるようになります。
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:
この PEP で使用されているいくつかの用語は、その範囲のコンテキストで複数の意味を持ちます。わかりやすくするために、この PEP では次の用語を特定の方法で使用します:
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.
distro
「ディストリビューション」の略で、さまざまな種類のソフトウェアの集合体で、理想的には適切に連携するように設計されており、(このドキュメントに関連するコンテキストでは) Python インタープリター自体、Python で記述されたソフトウェア、および他の言語で記述されたソフトウェアが含まれます。つまり、これは「Linux ディストリビューション」や「Berkeley Software Distribution」などのフレーズで使用される意味です。
ディストリビューションは、Debian、Fedora、FreeBSD などの独自のオペレーティング システム (OS) である場合があります。また、Homebrew や MacPorts などの既存の OS の上にインストールされるオーバーレイ ディストリビューションである場合もあります。
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.
このドキュメントでは、略語の「ディストリビューション」を使用しています。これは、「ディストリビューション」という用語が Python パッケージングのコンテキストでは別の意味を持つためです。つまり、setuptools.dist.Distribution または「sdist」の意味で、単一の Python 言語ソフトウェアのソースまたはバイナリ ディストリビューション パッケージです。混乱を避けるため、このドキュメントでは「ディストリビューション」という単純な用語は一切使用していません。Python パッケージングの意味で、完全なフレーズ「ディストリビューション パッケージ」または単に「パッケージ」を使用します (以下を参照)。
ディストリビューションのプロバイダー (ソフトウェアを収集して公開し、必要な変更を加えるチームまたは会社) は、そのディストリビューターです。
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.
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.
package(パッケージ)
Python 内でインストールして使用できるソフトウェアのユニット。つまり、これは Python 固有のパッケージング ツールで「ディストリビューション パッケージ」または単に「ディストリビューション」と呼ばれるものを指します。口語の略語「パッケージ」は、Python パッケージ インデックスの意味で使用されます。
このドキュメントでは、Python モジュールを含むインポート可能な名前という意味で「パッケージ」は使用していませんが、多くの場合、ディストリビューション パッケージは同じ名前の単一のインポート可能なパッケージで構成されています。
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.)
このドキュメントでは、通常、ディストリビューションのパッケージ マネージャーによるインストールの単位 (.deb ファイルや .rpm ファイルなど) を指すために「パッケージ」という用語を使用しません。必要な場合は、「ディストリビューションのパッケージ」などの表現を使用します。(繰り返しますが、多くの場合、Python パッケージは、python- に Python パッケージ名を加えたような名前のディストリビューションのパッケージ内に同梱されています。)
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 [1]; other examples include the old Easy Install command [2] as well as direct usage of a setup.py command.
(Conda [3] 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.)
Python-specific package manager(Python 固有のパッケージ マネージャー)
Python パッケージ標準 (PEP 376 や PEP 427 など) に準拠した方法で Python パッケージをインストール、アップグレード、および/または削除するためのツール。最も人気のある Python 固有のパッケージ マネージャーは pip [1] です。他の例としては、古い Easy Install コマンド [2] や setup.py コマンドの直接使用などがあります。
(Conda [3] は少し特殊なケースで、conda コマンドは Python パッケージ以外にも多くのものをインストールできるため、ある意味ではディストリビューション パッケージ マネージャーに似ています。conda コマンドは通常 Conda で作成された環境でのみ動作するため、このドキュメントのほとんどの懸念事項は、Python 固有のパッケージ マネージャーとして機能する conda には適用されません。)
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.
distro package manager(ディストリビューション パッケージ マネージャー)
ディストリビューションのインストール済みインスタンスでディストリビューションのパッケージをインストール、アップグレード、および/または削除するためのツール。Python パッケージだけでなく Python 以外のパッケージもインストールできるため、通常は PEP 376 とは関係のないインストール済みソフトウェアの独自のデータベースがあります。例としては、apt、dpkg、dnf、rpm、pacman、brew などがあります。顕著な特徴は、パッケージがディストリビューション パッケージ マネージャーによってインストールされた場合、Python 固有のパッケージ マネージャーを満足させる方法でパッケージを削除またはアップグレードすると、通常はディストリビューション パッケージ マネージャーが不整合な状態になるということです。
このドキュメントでは、特定のコンテキストでディストリビューション パッケージ マネージャーを指すために、「外部パッケージ マネージャー」や「システムのパッケージ マネージャー」などのフレーズも使用します。
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
shadow(シャドウ)
インストールされた Python パッケージをシャドウするとは、シャドウされたパッケージからファイルを削除せずに、他のパッケージをインポート用に優先させることです。これには、sys.path に複数のエントリが必要です。パッケージ A 2.0 がモジュール a.py を 1 つの sys.path エントリにインストールし、パッケージ A 1.0 がモジュール a.py を後の sys.path エントリにインストールする場合、import a は前者からモジュールを返し、A 2.0 が A 1.0 をシャドウすると言います。
関連ページ
コメント