Skip to content
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

pip install --dry-run {package} #8032

Closed
s-m-e opened this issue Apr 13, 2020 · 6 comments
Closed

pip install --dry-run {package} #8032

s-m-e opened this issue Apr 13, 2020 · 6 comments
Labels
auto-locked Outdated issues that have been locked by automation C: dependency resolution About choosing which dependencies to install type: feature request Request for a new feature

Comments

@s-m-e
Copy link

s-m-e commented Apr 13, 2020

What's the problem this feature will solve?

In certain scenarios I want to know whether pip could actually install a package and its dependencies - without modifying my Python installation at all.

Some of the related questions:

  • Can the dependency tree be fully resolved?
  • Are there conflicts?
  • Are all required packages available (in currently accessible online sources or local cache)?
  • Are packages involved which are not available as wheels and could therefore require a compiler etc. to work (i.e. is there a risk that the installation can fail because of missing/broken non-python tooling)?
  • Is the installation folder writable by the respective user, i.e. can the Python environment be modified?

Describe the solution you'd like

I want to be able to run pip install --dry-run {package}. The exit code of the process should indicate "should work" or "probably does not work". The output should provide detailed information.

Ideally, pip performs every operation necessary to install the package - except ultimately changing the current environment. It may (and should) therefore download dependencies, build wheels where applicable, etc.

Real world uses: Similar to plenty of other package management tools which do implement this feature, I see the primary use in head-less, automated installs - i.e. where pip is not triggered by a user but by other tools and software packages. This feature would allow a much more graceful (in advance) handling of failures.

Alternative Solutions

There are plenty of bad and/or risky and/or notoriously unreliable and/or resource-intensive workarounds. Examples:

  • Using pip-sync -n (i.e. a third party tool) which has a few massive limitations here
  • Using hacks like pip freeze | grep -f requirements.txt | sort | diff -y --suppress-common-lines - <(sort requirements.txt) which assume that you have a requirements.txt file available - again plenty of problems and unsolvable edge cases
  • Temporarily creating a new Python (virtual) environment (ideally cloning the target environment somehow), then installing into the temporary environment, then analyzing the outcome (and the difference between the temporary and the target environment).

Additional context

This topic is not new. For reference:

@triage-new-issues triage-new-issues bot added the S: needs triage Issues/PRs that need to be triaged label Apr 13, 2020
@sbidoul
Copy link
Member

sbidoul commented Apr 13, 2020

This sounds like a good feature request and one I have been pondering about too.

A slightly different way to frame it is to say "--dry-run" should output the list of transactions that pip install would apply to the database of installed distributions (PEP 376). I.e. which packages would be added, upgraded, and possibly left unchanged.

A machine readable output would enable higher level use cases such as the creation of a lockfile from a list of top level requirements (à la pip-compile), by running it in an empty environment.

Such a use case does not necessarily require building of all dependencies (only obtaining their metadata). So full build of dependencies could be an option.

@uranusjr
Copy link
Member

A problem with --dry-run is that pip can’t really run an installation truly “dry”, since it always needs to build source and sdist. Something like pip install --no-install might make more sense technically, but can be nonsensical to read.

@s-m-e
Copy link
Author

s-m-e commented Apr 13, 2020

@uranusjr Building source and sdist should definitely be part of a proper "dry run". If it fails, it means that the dry run fails meaning that an actual "wet" installation would also fail. This is highly valuable information though I'd also agree with @sbidoul that it could be made optional (e.g. --dry-run --no-dry-builds).

@sbidoul sbidoul added C: dependency resolution About choosing which dependencies to install type: feature request Request for a new feature labels Apr 13, 2020
@triage-new-issues triage-new-issues bot removed the S: needs triage Issues/PRs that need to be triaged label Apr 13, 2020
@pradyunsg
Copy link
Member

I'm pretty sure there's an existing issue for this feature request.

@pradyunsg
Copy link
Member

pradyunsg commented Apr 15, 2020

Closing as a duplicate of #53. That issue can use a cleanup; so I'll do some "housekeeping" on that issue. FWIW, there's also #7819, which is actually an implemented proposal for adding a new pip resolve command.

@pradyunsg
Copy link
Member

Okay, housekeeping done. If someone thinks what I did there was inappropriate, please holler here. :P

@lock lock bot added the auto-locked Outdated issues that have been locked by automation label May 20, 2020
@lock lock bot locked as resolved and limited conversation to collaborators May 20, 2020
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 C: dependency resolution About choosing which dependencies to install type: feature request Request for a new feature
Projects
None yet
Development

No branches or pull requests

4 participants