refactor the non_host part for not injecting to custom env

[xiacunshun]

fix: #343

We can get the sitepackages directory from the given interpreter directly instead of running our code again with it.

[xiacunshun]

I think the result of this method is the same with the original one. Please take a look if you have time. @kemzeb

[kemzeb]

Hmm, I noticed that when we're using a venv that has system site packages enabled (i.e. I did python -m venv --system-site-packages venv), running the following:

pipdeptree --python path/to/python --local-only

...would cause us to hit the else branch (since I am not running in a virtual environment). We don't want this since we will use paths to metadata from the entire environment.

I think what we need to do here is if --python and --local are given, we should grab the result of:

"str(py_path), "-c", "import sys, site; print(site.getsitepackages([sys.prefix]))"

...and pass it to distributions(). Otherwise, use sys.path.

[xiacunshun]

Hmm, I noticed that when we're using a venv that has system site packages enabled (i.e. I did python -m venv --system-site-packages venv), running the following:

pipdeptree --python path/to/python --local-only

...would cause us to hit the else branch (since I am not running in a virtual environment). We don't want this since we will use paths to metadata from the entire environment.

I think what we need to do here is if --python and --local are given, we should grab the result of:

"str(py_path), "-c", "import sys, site; print(site.getsitepackages([sys.prefix]))"

...and pass it to distributions(). Otherwise, use sys.path.

That's a really good situation which I didn't notice. I will add some tests to cover this too.

[kemzeb]

FYI once we merge this I'll make a 2.18.0 release.

[kemzeb]

Can't see any other issues, so it looks like this is good to go. Will release 2.18.0 after merging

[kemzeb]

Looks like we're good to go, releasing 2.18.0