A VersionConflict exception when a system installed package conflicts with a pinned requirements package about python-license-check HOT 7 CLOSED

Thank you for the bug report and the test case. I am looking into it.

from python-license-check.

We are using pkg_resources.working_set to find required packages, but this working set includes what is already installed so that can raise unexpected version conflicts. It would be better to find required packages from a clean environment (kind of venv). Still digging to find a way to achieve that...

from python-license-check.

It would be better to find required packages from a clean environment (kind of venv).

FWIW setuptools is installed alongside with every virtual environment (pip and wheel as well).

from python-license-check.

The solution could be excluding pip, setuptools, and wheel from passing to pkg_resources.working_set, assuming they are MIT licensed 🤔

UPDATE: or get their licenses from JSON API.

from python-license-check.

I love the idea of the JSON API. We would no longer have to hack the pip and pkg_resources APIs. But this is not a trivial update.

from python-license-check.

Originally this issue was caught due to another issue with poetry python-poetry/poetry#1584, where poetry wouldn't update setuptools in virtualenv.

I love the idea of the JSON API. We would no longer have to hack the pip and pkg_resources APIs. But this is not a trivial update.

JSON API doesn't show dependencies for packages that list their dependencies in a non-declarative way (e.g., using setup(install_requires=[...])).

The --no-deps option (#48) would help, where resolving dependencies would be a dependency managers' job (e.g., pip-tools/pipenv/poetry/...).

@ochedru I wonder what would you think?

from python-license-check.

I am fine with your PR; it looks like we cannot rely on the JSON API and the --no-deps option will help dealing with difficult cases.
So, 👍

from python-license-check.