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

Display type of latest version in pip list --outdated #2475

Closed
pfmoore opened this Issue Mar 4, 2015 · 7 comments

Comments

Projects
None yet
3 participants
@pfmoore
Member

pfmoore commented Mar 4, 2015

Usually, when I run pip list --outdated I want to see not only what packages are out of date, but whether the new version supplies a wheel. When a package is hard to build, knowing whether a wheel is available can be the deciding factor over whether to upgrade.

Suggested output format:

win-unicode-console (Current: 0.3 Latest: 0.3.1 [sdist])
youtube-dl (Current: 2015.1.11 Latest: 2015.3.3.1 [wheel])

I have a patch that does this (it's just a matter of returning the link extension from find_packages_latests_versions), but at the moment it lacks tests. PR following once I have added tests.

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Mar 4, 2015

Member

PR #2476 created for this

Member

pfmoore commented Mar 4, 2015

PR #2476 created for this

@piotr-dobrogost

This comment has been minimized.

Show comment
Hide comment
@piotr-dobrogost

piotr-dobrogost Mar 4, 2015

Shouldn't that be the list of all available formats instead? Someone might be interested in new version only when there's sdist available for example and in this case when he sees wheel he does not know if sdist is available or not.

piotr-dobrogost commented Mar 4, 2015

Shouldn't that be the list of all available formats instead? Someone might be interested in new version only when there's sdist available for example and in this case when he sees wheel he does not know if sdist is available or not.

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Mar 4, 2015

Member

Well, finder.find_requirement only returns one item, which is what pip is going to install, so that's what I display. The use case is for people who can't install the new version unless there is a wheel, and want to know not to bother trying.

Are there really any packages which provide a wheel but not a sdist? Or for that matter, any real world scenarios where you would not install from a wheel if one were available?

Member

pfmoore commented Mar 4, 2015

Well, finder.find_requirement only returns one item, which is what pip is going to install, so that's what I display. The use case is for people who can't install the new version unless there is a wheel, and want to know not to bother trying.

Are there really any packages which provide a wheel but not a sdist? Or for that matter, any real world scenarios where you would not install from a wheel if one were available?

@piotr-dobrogost

This comment has been minimized.

Show comment
Hide comment
@piotr-dobrogost

piotr-dobrogost Mar 4, 2015

I have no idea - that's what instantly came to my mind after reading.

piotr-dobrogost commented Mar 4, 2015

I have no idea - that's what instantly came to my mind after reading.

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Mar 4, 2015

Member

There are packages that provide a Wheel but not a sdist. Mostly these are people publish pre-release software of pure Python projects. It's exploiting the fact that only pip 1.4+ can install Wheels, but that pip 1.4+ also won't install a pre-release by default.

Member

dstufft commented Mar 4, 2015

There are packages that provide a Wheel but not a sdist. Mostly these are people publish pre-release software of pure Python projects. It's exploiting the fact that only pip 1.4+ can install Wheels, but that pip 1.4+ also won't install a pre-release by default.

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Mar 4, 2015

Member

@dstufft OK, but seeing [wheel] for such packages doesn't seem to me to be an issue. To get a surprising result the user would need to see [wheel] and then deliberately do pip install --no-use-wheel, and not anticipate that there might not be a sdist. If anyone has a real use case for such a scenario, I'd support adding a -no-use-wheel argument to pip list, to make the output match what pip install will do with that argument, but it seems like YAGNI to me.

This change satisfies a genuine need I have, so I'm inclined to put it in as it stands, and let anyone with more complex needs update it later.

Member

pfmoore commented Mar 4, 2015

@dstufft OK, but seeing [wheel] for such packages doesn't seem to me to be an issue. To get a surprising result the user would need to see [wheel] and then deliberately do pip install --no-use-wheel, and not anticipate that there might not be a sdist. If anyone has a real use case for such a scenario, I'd support adding a -no-use-wheel argument to pip list, to make the output match what pip install will do with that argument, but it seems like YAGNI to me.

This change satisfies a genuine need I have, so I'm inclined to put it in as it stands, and let anyone with more complex needs update it later.

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Mar 5, 2015

Member

Closed via #2476

Member

pfmoore commented Mar 5, 2015

Closed via #2476

@pfmoore pfmoore closed this Mar 5, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment