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-sync will happilly uninstall all packages if requirements.txt is empty #671

Closed
takeda opened this issue Aug 1, 2018 · 9 comments
Closed
Labels
feature Request for a new feature needs discussion Need some more discussion

Comments

@takeda
Copy link

takeda commented Aug 1, 2018

This perhaps might be argued to be a feature, since pip-sync supposed to uninstall anything that is not in requirements.txt but this is dangerous in scenarios when an earlier operation has failed and caused requirements.txt to be empty. I'm wondering whether this safety measure could be added, if someone needs the behavior, maybe they can specify --force?

Environment Versions
  1. OS Type: N/A
  2. Python version: $ python -V: N/A
  3. pip version: $ pip --version: 18.0
  4. pip-tools version: $ pip-compile --version: 2.0.2
Steps to replicate
  1. echo -n > test.txt
  2. pip-sync test.txt
  3. pip list
Expected result

Operation would fail

Actual result

All packages were uninstalled

@georgek
Copy link
Contributor

georgek commented Jul 2, 2019

Seems like pip-sync is doing the right thing to me. Always check the input to your programs before you run them.

@takeda
Copy link
Author

takeda commented Jul 2, 2019

Heh, since I wrote this PR I ended up liking this behavior and started using pip-sync /dev/null to cleanup the environment, before installing something else.

My concern when filling this PR was using pip-sync in CMS code (salt, chef, puppet etc) for the purpose of deployment in case precious step failed and produced an empty file. Maybe an option --fail-on-empty could be used as a safety measure.

@georgek
Copy link
Contributor

georgek commented Jul 2, 2019

Why not check the previous file with another tool like wc? Unix philosophy: do one thing and do it well.

@atugushev
Copy link
Member

I think we can ask if a user wants to continue. For example:

if file_is_empty and not click.confirm('Do you want to uninstall all packages?'):
    sys.exit(0)

@georgek
Copy link
Contributor

georgek commented Sep 16, 2019

Personally I'm against training users that commands can't do something dangerous. They'll get a shock when rm -rf / doesn't ask if they are sure.

Another concern is what if I really do want to do this? We'll need another option like --yes for running it in a non-interactive environment like CI.

@atugushev
Copy link
Member

Another concern is what if I really do want to do this? We'll need another option like --yes for running it in a non-interactive environment like CI.

That makes sense. But I don't mind honestly, for I remember how I got myself into this trap once and deleted all packages in the env.

@AndydeCleyre
Copy link
Contributor

Uninstalling all packages is exactly what I expect and desire to happen when I pip-sync against an empty file.

@atugushev atugushev added feature Request for a new feature needs discussion Need some more discussion labels Sep 19, 2019
@georgek
Copy link
Contributor

georgek commented Sep 27, 2019

A nicer option would be to add an "opt-in" feature, ie. an --ask flag similar to how nmcli or portage (Gentoo package manager) works. Users can then use this in an alias if they wish for it to be enabled on their interactive command line but it won't affect CI or users who don't like such features.

I think --ask would simply be --dry-run, but with the option to continue with a real run.

@atugushev
Copy link
Member

atugushev commented Oct 8, 2019

I'll close this based on the above which was implemented in #913, but please let us know if it doesn't resolve your issue. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Request for a new feature needs discussion Need some more discussion
Projects
None yet
Development

No branches or pull requests

4 participants