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 --upgrade-package removes "via" annotation from lock file #929

Closed
tuukkamustonen opened this issue Oct 8, 2019 · 2 comments · Fixed by #931
Closed

pip-compile --upgrade-package removes "via" annotation from lock file #929

tuukkamustonen opened this issue Oct 8, 2019 · 2 comments · Fixed by #931
Assignees
Labels
annotations Related to packages annotations bug Something is not working PR wanted Feature is discussed or bug is confirmed, PR needed

Comments

@tuukkamustonen
Copy link

pip-compile --upgrade removes source annotations (e.g. # via jinja2).

Environment Versions

  1. OS Type: Linux
  2. Python version: 3.6.6
  3. pip version: 19.2.3
  4. pip-tools version: 4.1.0

Steps to replicate

Prepare virtualenv:

$ pyenv install 3.6.6 py36
$ pyenv activate py36
$ pip install -U pip pip-tools

Prepare lock file:

$ echo "jinja2" > requirements.in
$ pip-compile --no-header --no-index
jinja2==2.10.3
markupsafe==1.1.1         # via jinja2
$ # edit requirements.txt and change markupsafe version to 1.0.0
$ cat requirements.txt
jinja2==2.10.3
markupsafe==1.0.0         # via jinja2

Let's upgrade markupsafe:

$ pip-compile -P markupsafe --no-header --no-index
jinja2==2.10.3
markupsafe==1.1.1

Problem is that # via jinja2 marker was removed. --upgrade-package shouldn't remove the annotation, as intention was merely to upgrade it. It is still required via jinja2 and not directly (it's not in requirements.in)

On the other hand, I understand that I now directly influenced the package version, so annotation gets removed. But still, my initial assumption was that marker would remain.

So I am not sure about this one. Is current behavior intentional?

@atugushev
Copy link
Member

atugushev commented Oct 8, 2019

Hello @tuukkamustonen,

Thanks for the good catch and easy reproducer!

So I am not sure about this one. Is current behavior intentional?

It's a bug.

@atugushev atugushev added bug Something is not working PR wanted Feature is discussed or bug is confirmed, PR needed labels Oct 8, 2019
@atugushev
Copy link
Member

atugushev commented Oct 8, 2019

That's because packages to update accidentally become primary packages. For those who want to fix it:

diff --git a/piptools/scripts/compile.py b/piptools/scripts/compile.py
index 6415227..9624684 100755
--- a/piptools/scripts/compile.py
+++ b/piptools/scripts/compile.py
@@ -326,6 +326,10 @@ def cli(
                 )
             )
 
+    primary_packages = {
+        key_from_ireq(ireq) for ireq in constraints if not ireq.constraint
+    }
+
     constraints.extend(upgrade_install_reqs.values())
 
     # Filter out pip environment markers which do not match (PEP496)
@@ -415,9 +419,7 @@ def cli(
         results=results,
         unsafe_requirements=resolver.unsafe_constraints,
         reverse_dependencies=reverse_dependencies,
-        primary_packages={
-            key_from_ireq(ireq) for ireq in constraints if not ireq.constraint
-        },
+        primary_packages=primary_packages,
         markers={
             key_from_ireq(ireq): ireq.markers for ireq in constraints if ireq.markers
         },

@hramezani hramezani self-assigned this Oct 9, 2019
@atugushev atugushev added the annotations Related to packages annotations label Apr 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
annotations Related to packages annotations bug Something is not working PR wanted Feature is discussed or bug is confirmed, PR needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants