pypa/packaging.python.org — Spanish @ Hosted Weblate: This specification is twofold.

Zen

	English	Spanish	Actions
	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 the :ref:`database of installed distributions <recording-installed-packages>`. 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.
	This specification is twofold.	Especificaciones de PyPA
	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`` 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.
	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:

Loading…

None

String updated in the repository

English

Spanish 0 characters edited Current translation Needs editing

2 months ago

None

String updated in the repository

English

Spanish 24 characters edited Current translation Needs editing

7 months ago

None

Source string changed

English 15 characters edited

7 months ago

Browse all string changes

Things to check

Mismatched full stop

Source and translation do not both end with a full stop

Reset

Glossary

English	Spanish
No related strings found in the glossary.

String information

Flags

placeholders:BigQuery:easy_install:HTML:HTTP:Linux:pip:PSF:PyPI:Python:setuptools:venv:virtualenv:Windows:":pep:`440`":``pip``:``setuptools``:"::":|PyPUG|, rst-text

Source string location

../source/specifications/externally-managed-environments.rst:132

String age

7 months ago

Last updated

3 days ago

Source string age

7 months ago

Translation file

locales/es/LC_MESSAGES/messages.po, string 2397