Skip to content
This repository was archived by the owner on Mar 27, 2024. It is now read-only.

pip packages missing from diff when size couldn't be retrieved #281

Closed
weakcamel opened this issue Jan 4, 2019 · 2 comments
Closed

pip packages missing from diff when size couldn't be retrieved #281

weakcamel opened this issue Jan 4, 2019 · 2 comments

Comments

@weakcamel
Copy link

weakcamel commented Jan 4, 2019

I've noticed container-diff inconsistently handles the diff operation between apt and pip analyzers. Example below:

$ container-diff diff --json --type pip --type apt daemon://<image> daemon://ubuntu:xenial-20180417 >package_diff.json

...
Extracting container diff to logs/package_diff.json
time="2019-01-04T11:06:29Z" level=error msg="Could not get size for smproteus-1.0: strconv.ParseInt: parsing \"3.0 kB\": invalid syntax"
time="2019-01-04T11:06:29Z" level=error msg="Could not get size for smpipeline: strconv.ParseInt: parsing \"13 kB\": invalid syntax"
time="2019-01-04T11:06:29Z" level=error msg="Could not find Python package PyYAML for corresponding metadata info" 
time="2019-01-04T11:06:30Z" level=error msg="Could not find Python package PyYAML for corresponding metadata info"

...

$ grep -iC3 smpipeline package_diff.json 
          "Size": 9064448
        },
        {
          "Name": "smpipeline",
          "Version": "2.4.20",
          "Size": -1024
        },

The two packages (smproteus-1.0, smpipeline) are proprietary debs which are listed in the diff (with Size: -1024) , PyYAML is a pypi package and is not listed in the report.

The corresponding line is:

Expected behavior

IMO, it would be much more graceful to report the PIP package no matter what, just skipping the size (or reporting it as an obviously wrong value, e.g.

      { 
        "Name": "PyYAML",
        "Path": "/usr/local/lib/python3.5/dist-packages",
        "Version": "3.12",
        "Size": -1024
      },

or

      { 
        "Name": "PyYAML",
        "Path": "/usr/local/lib/python3.5/dist-packages",
        "Version": "3.12"
      },

Actual behavior

The pip package where container-diff couldn't deduce the size is missing entirely from the diff:

$ grep -iC3 pyyaml package_diff.json 
$

Information

  • container-diff version: v0.14
  • Operating system: MacOS

Steps to reproduce the behavior

  1. Create a Dockerfile with the following content:
FROM ubuntu:xenial-20180417
ENV DEBIAN_FRONTEND noninteractive
RUN apt-get update -qq  && apt-get install -qqy python3-pip && \
    pip3 install PyYAML
  1. build your image:
$ docker build -t img:latest .
Sending build context to Docker daemon  2.048kB
Step 1/3 : FROM ubuntu:xenial-20180417
 ---> 0b1edfbffd27
Step 2/3 : ENV DEBIAN_FRONTENT noninteractive
 ---> Using cache
 ---> fdb8457195c9
Step 3/3 : RUN apt-get update -qq  && apt-get install -qqy python3-pip &&     pip3 install PyYAML
 ---> Using cache
 ---> b86420bea1cd
Successfully built b86420bea1cd
Successfully tagged img:latest
  1. Run the container-diff and observe the output:
$ container-diff diff --json --type pip daemon://img:latest daemon://ubuntu:xenial-20180417
ERRO[0022] Could not find Python package PyYAML for corresponding metadata info 
ERRO[0022] Could not find Python package PyYAML for corresponding metadata info 
[
  {
    "Image1": "img:latest",
    "Image2": "ubuntu:xenial-20180417",
    "DiffType": "Pip",
    "Diff": {
      "Packages1": [],
      "Packages2": [],
      "InfoDiff": []
    }
  }
]
@nkubala
Copy link
Contributor

nkubala commented Jan 23, 2019

@weakcamel thanks for the issue, and sorry for the late reply!

I did some investigating today and it looks like there are a few improvements that need to be made here to fix this issue. I found the underlying cause of your issue and addressed it here, but I agree that container-diff should be a bit more graceful with its results when errors are encountered, or at the very least should be consistent. I'll work on a fix for that as well.

I'll keep you posted when all the fixes are merged, so I can get a release out and have you try and make sure everything is good :)

@weakcamel
Copy link
Author

@nkubala many thanks for looking into it!

I'll be very happy to test it once the release (or some rc) is out.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants