Skip to content

Record pip in INSTALLER file #3284

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 19, 2016
Merged

Conversation

ncoghlan
Copy link
Member

@ncoghlan ncoghlan commented Dec 4, 2015

When installing from a wheel archive (whether directly, or by building a wheel file from a source format), generate and install an INSTALLER metadata file indicating that "pip" handled the installation.

This initial implementation is hardcoded to use "pip\n" as the identifier.

Review on Reviewable

@domenkozar
Copy link
Contributor

@ncoghlan would it make sense to also record the version number?

@pfmoore
Copy link
Member

pfmoore commented Dec 17, 2015

@domenkozar The PR is implementing the INSTALLER file as defined in PEP 376. See https://www.python.org/dev/peps/pep-0376/#installer which doesn't allow for a version number in the file. (That's not to say it's impossible, as PEP 376 is at best incompletely supported by tools, and could be amended, but interoperability is a tricky subject, and I'd say we should follow the published standard even if it's not widely used in preference to creating our own subtly incompatible variant).

@domenkozar
Copy link
Contributor

@pfmoore understood.

@ncoghlan
Copy link
Member Author

The main eventual use case here is to avoid pip accidentally stepping on system packages when run with root privileges, since you can foul up a Linux system pretty badly doing that. The version of the installer doesn't matter for that purpose, just the name - we'd like pip to be able to give a warning when asked to upgrade or remove something it didn't install.

Longer term, something more like the metadata file in the wheel format would likely be nicer, but the PEP 376 scheme has the advantage of already being defined and partially adopted (pip writes RECORD in order to handle uninstalls).

@dstufft dstufft added this to the 8.0 milestone Jan 19, 2016
dstufft added a commit that referenced this pull request Jan 19, 2016
@dstufft dstufft merged commit 3b3978b into pypa:develop Jan 19, 2016
@szepeviktor
Copy link
Contributor

How is it possible now to distinguish between pip-installed and Debian python packages?

@ncoghlan
Copy link
Member Author

It's unfortunately not reliable to do so yet, as distros haven't set policies for dealing with INSTALLER files (e.g. if the system package is using pip to do the installation during the package build process, INSTALLER may still claim "pip").

There's a current discussion on distutils-sig about that, and once PyPA has articulated how we'd like distros to handle the file, then distros can update their policies accordingly.

@szepeviktor
Copy link
Contributor

Thank you very much for clarifying these.

@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 3, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants