-
Notifications
You must be signed in to change notification settings - Fork 3k
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 list
should tell the truth and provide more info
#1714
Comments
related issue: #1646 : "implement INSTALLER from PEP376" |
Certainly pip list should report the INSTALLER info. Even if pip doesn't write it yet, other installers (like the OS package manager) could start doing so and that would give Barry the information he's after. Whether it's right to not list things that are installed and importable, but weren't installed by pip, I'm not so sure of. I use |
I agree we should not hide something from |
On Apr 10, 2014, at 10:16 AM, Donald Stufft wrote:
Maybe the default for |
-1 on defaulting to anything other than all available distributions. Generally, I use |
I agree with Paul. OS packages started including egg-info metadata precisely to allow Python-level installers (at the time, easy_install) to see what was already available. |
-1 on changing the default. I also like the idea of a flag to limit output, I'm hoping to still implement that. |
Closing this as we're not going to limit the output to hide system install packages, however it would be useful to mention if they were installed by the system or pip. Fortunately we have an issue for that already, which is #949. |
Currently
pip list
gives me some output indicating installed packages, but this is misleading. All of the packages displayed are really installed by my OS package manager so really aren't part of pip's responsibility.There should be a way for pip to only report packages that were actually installed by pip.
Also,
pip info -v
should display the paths it found the packages in. Otherwise, it doesn't seem possible to know whether they are installed in ~/.local or /usr/local (or in the above case, /usr).The text was updated successfully, but these errors were encountered: