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-compile upgrades a package even it doesn't exist in a requrements.* #759

Closed
atugushev opened this issue Mar 7, 2019 · 8 comments · Fixed by #1031
Closed

Pip-compile upgrades a package even it doesn't exist in a requrements.* #759

atugushev opened this issue Mar 7, 2019 · 8 comments · Fixed by #1031
Assignees
Labels
bug Something is not working PR wanted Feature is discussed or bug is confirmed, PR needed

Comments

@atugushev
Copy link
Member

atugushev commented Mar 7, 2019

Pip-compile should raise an error while trying to upgrade a package which doesn't exist in a requirements.in.

Environment Versions
  1. OS Type: any
  2. Python version: any
  3. pip version: any
  4. pip-tools version: any
Steps to replicate
  1. echo "click" > requirements.in
  2. pip-compile
  3. pip-compile -P django
Expected result

Raise a error/warning or skip non-existing package.

Actual result
#
# This file is autogenerated by pip-compile
# To update, run:
#
#    pip-compile -P pytz
#
click==7.0
django==1.11.20
pytz==2018.9
@atugushev atugushev added the bug Something is not working label Mar 7, 2019
@atugushev atugushev changed the title Pip-compile upgrades a package even it doesn't exist in a requrements.in Pip-compile upgrades a package even it doesn't exist in a requrements.* Mar 27, 2019
@pawciobiel
Copy link

It's not clear if -P should or shouldn't work with SRC *in and/or DST *.txt requirements files. Would it make sense if pip-compile -P django requirements.in raise error but not pip-compile -P django ?

@atugushev
Copy link
Member Author

Hello @pawciobiel,

if pip-compile -P django requirements.in raise error but not pip-compile -P django

What's the difference between those commands? Why they should have different behavior?

@AndydeCleyre
Copy link
Contributor

AndydeCleyre commented Sep 17, 2019

IMO it would be best for this to skip non-existing packages with a warning, rather than an error. That way I could safely loop through different .in files, upgrading a specified package if and only if it exists, without needing to check if a failure is a "real" problem or just an inappropriate upgrade attempt.

FWIW, I'm using these Zsh functions to wrap pip-compile -P and pip-compile -U:

# recompile *requirements.txt with upgraded versions of all or specified packages (upgrade)
pipu () {  # [req...]
    local reqs=($@)
    for reqsin in *requirements.in(N); do
        print -rP "%F{cyan}> upgrading ${reqsin:r}.txt <- $reqsin . . .%f"
        if [[ $# -gt 0 ]]; then
            pip-compile --no-header ${${@/*/-P}:^reqs} $reqsin 2>&1 | hpype
            pipc $reqsin  # can remove if https://github.com/jazzband/pip-tools/issues/759 gets fixed
        else
            pip-compile --no-header -U $reqsin 2>&1 | hpype
        fi
    done
}
# upgrade with hashes
pipuh () {  # [req...]
    local reqs=($@)
    for reqsin in *requirements.in(N); do
        print -rP "%F{cyan}> upgrading ${reqsin:r}.txt <- $reqsin . . .%f"
        if [[ $# -gt 0 ]]; then
            pip-compile --no-header --generate-hashes ${${@/*/-P}:^reqs} $reqsin 2>&1 | hpype
            pipch $reqsin  # can remove if https://github.com/jazzband/pip-tools/issues/759 gets fixed
        else
            pip-compile --no-header -U --generate-hashes $reqsin 2>&1 | hpype
        fi
    done
}

@atugushev
Copy link
Member Author

@AndydeCleyre, probably, warning+skip is better than an error indeed. Thanks for the suggestion!

@atugushev atugushev added the PR wanted Feature is discussed or bug is confirmed, PR needed label Oct 17, 2019
@tuukkamustonen
Copy link

tuukkamustonen commented Oct 18, 2019

I second the need for not raising error. And in my case (#950), I wouldn't want even warning.

Maybe --upgrade-package and --upgrade-only-package or something?

@AndydeCleyre
Copy link
Contributor

@atugushev I've implemented a very small change that seems to do "the right thing," with a simple test. I don't know that there's a strong case for errors or warnings in this case, so there are none raised in my PR.

You mentioned in your WIP PR that there was a complication with "upgrading subdependencies" -- can you elaborate with an example to demonstrate the expectation?

@atugushev
Copy link
Member Author

@AndydeCleyre

You mentioned in your WIP PR that there was a complication with "upgrading subdependencies" -- can you elaborate with an example to demonstrate the expectation?

There were a few edge cases with sub-deps. Some of them, probably, wouldn't relevant if we don't want to raise a error/warning. I'll elaborate on these cases in your PR.

@atugushev
Copy link
Member Author

atugushev commented Jan 18, 2020

FTR, I've updated the "Expected result" in the issue description, since both variants fine by me.

AndydeCleyre added a commit to AndydeCleyre/pip-tools that referenced this issue Jan 18, 2020
…exclude -P args not already pinned or primarily required; fixes jazzband#759
AndydeCleyre added a commit to AndydeCleyre/pip-tools that referenced this issue Jan 19, 2020
…exclude -P args not already pinned or primarily required; fixes jazzband#759

Co-Authored-By: Albert Tugushev <albert@tugushev.ru>

use long option style --upgrade-package in test

exact line-matching in expected output

more readable if/else instead of ternary
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something is not working PR wanted Feature is discussed or bug is confirmed, PR needed
Projects
None yet
4 participants