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 list should tell the truth and provide more info #1714

Closed
warsaw opened this issue Apr 10, 2014 · 8 comments
Closed

pip list should tell the truth and provide more info #1714

warsaw opened this issue Apr 10, 2014 · 8 comments
Labels
auto-locked Outdated issues that have been locked by automation

Comments

@warsaw
Copy link

warsaw commented Apr 10, 2014

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).

@qwcode
Copy link
Contributor

qwcode commented Apr 10, 2014

related issue: #1646 : "implement INSTALLER from PEP376"

@pfmoore
Copy link
Member

pfmoore commented Apr 10, 2014

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 pip list to see what's available and I'd expect to see something even if it wasn't installed by pip (as long as I could import/use it).

@dstufft
Copy link
Member

dstufft commented Apr 10, 2014

I agree we should not hide something from pip list just because we didn't install it. I'm OK with a flag that says pip list -only-pip or something. And I'm OK with making it obvious which things in pip list are installed by pip and which aren't.

@warsaw
Copy link
Author

warsaw commented Apr 10, 2014

On Apr 10, 2014, at 10:16 AM, Donald Stufft wrote:

I agree we should not hide something from pip list just because we didn't
install it. I'm OK with a flag that says pip list -only-pip or
something. And I'm OK with making it obvious which things in pip list are
installed by pip and which aren't.

Maybe the default for pip list should only be the things that pip has
responsibility for, i.e. the things it can remove. You can't pip remove
any packages installed by the system. Thus pip list should probably gain
a --everything switch to opt-into printing everything.

@pfmoore
Copy link
Member

pfmoore commented Apr 10, 2014

Maybe the default for pip list should only be the things that pip has
responsibility for, i.e. the things it can remove. You can't pip remove
any packages installed by the system.

-1 on defaulting to anything other than all available distributions.

Generally, I use pip list to see what's installed, not to see what I can remove. So I'd argue for a default of everything, and a flag to limit to only pip-installed projects (maybe something like --installer=pip where the --installer flag selects based on what's in INSTALLER).

@merwok
Copy link

merwok commented Nov 21, 2014

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.

@Ivoz
Copy link
Contributor

Ivoz commented Dec 6, 2014

-1 on changing the default.

I also like the idea of a flag to limit output, I'm hoping to still implement that.

@dstufft
Copy link
Member

dstufft commented Mar 22, 2017

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.

@dstufft dstufft closed this as completed Mar 22, 2017
@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 3, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation
Projects
None yet
Development

No branches or pull requests

6 participants