Add "outdated" pip command

[dgladkov]

This command lists all installed (or only local) packages that can be updated. Basically it performs search for all installed package names in one XML-RPC request, filters only installed packages (there is no way to do exact match) and displays only those, which version differ from the latest version on PyPI.

I don't know why something like that wasn't implemented earlier - and maybe there is a reason for that - but I'm unaware of it:)

Also I added basic test for this command, but I haven't tested --local and --index options yet.

[jezdez]

I'm not convinced this should get its own command since it's really just a subset of what we've discussed an "info" command could show. E.g. pip info --outdated could show the outdated packages, while pip info shows all installed.

[dgladkov]

If pip info shows only installed packages, what's the difference between pip info and pip freeze? Perhaps pip info could display package description the same way pip search does, but I'm not sure this will be useful.

Could you please point me a link to the discussion about pip info if it's in public or describe here or in GitHub issue what you believe needs to be done?

[jezdez]

The difference between info and freeze is its purpose. info shows information about a package, while freeze generates a requirements file listing.

[carljm]

Hi dgladkov, thanks for this contribution! In general I agree with jezdez that "outdated" is quite specific functionality to deserve its own top-level command, and I'd rather see it as a flag to a general "show installed packages" command. I'm not sure about the name pip info - it seems so general that it could mean almost anything. I kind of like pip status. But that's just bikeshedding.

Re where that discussion happened previously, it was on some tickets I believe, though I can't find them at the moment.

The other thing I wonder about this patch is that it kind of makes the assumption that everything is listed on PyPI, even though that's not really true. I often use custom indexes, find-links, etc, and these things don't have an XMLRPC interface. A more flexible "outdated" command would not use XMLRPC, it would actually use PackageFinder to go out looking for updated versions in the same way "install" does, and would thus be able to handle options like --index-url and --find-links. Of course, this would be slower... and in the long run I think we (i.e. Python packaging infrastructure) should be moving away from link-scraping. But in the short run it feels strange to me to introduce new features that make inflexible and incorrect assumptions about how people use pip.

At the very least I think this patch should check > not != when comparing versions. I will quite commonly have a more recent pre-release or beta-release of something installed than the latest that is on PyPI, and it would be wrong to have those listed as "outdated" when they are in fact the opposite.

[xster]

Hi,

As a user, I think that this functionality is quite urgent regardless of how it would be called.
As of the naming/commands, I would suggest that a 'list' and an 'info' command generally seems to work fine. Listing of outdated (and other filtered) packages can be a subset of a list command. Otherwise, macports and homebrew have a dedicated 'outdated' command as well.

[douglas]

Im with @xster here. Hope this code is merged soon.

[Uznick]

This functionality is very important. Will it be merged anytime soon? :)

And I vote for dedicated 'outdated' command.

[douglas]

Any news on this issue ?

[Uznick]

Nobody cares?

[carljm]

Hmm, I commented above on why this implementation doesn't seem like the right approach, given that not all packages come from PyPI - haven't seen any response to that yet.

[jezdez]

Yeah, I think we can all agree that the feature is useful, only that the patch needs improvement as mentioned above.

[maraujop]

Hi Carl,

I finally managed to upgrade pip outdated by @dgladkov so that it uses PackageFinder. Former version from @dgladkov failed to run in my computer, because of some packages I had. This one works, which doesn't mean is bug free.

I'm using a "private" method to get the local version installed, as you can see in my comments. I'm willing to update anything necessary so that this gets merged into master.

I've been thinking, that instead of using a dictionary installations we could use a RequirementSet and outdated command could get a parameter like --upgrade which also upgrade packages. That would probably make having a separate command for this more understandable.

Cheers,
Miguel

[jezdez]

Just wanted to give a quick idea for the command -- let's have a pip list command that gets a bunch of flags:

• --outdated Returns a list of requirements that are outdated as request in this ticket
• --uptodate Returns a list of requirements that are up-to-date
• --local Returns a list of non-editable requirements
• --editable Returns a list of editable requirements
• --freeze An additive flag that formats the output in requirements files format

etc.

With the last option we'd be able to deprecate the freeze command (or simply hide it from pip help and promoting the use of pip list --freeze instead).

[jezdez]

BTW, given the fact that the other commands are imperatives, pip list fits better than pip status, IMO.

[maraujop]

Hi,

As I said in the IRC channel. I'm in favor of a pip list command and I can work on it. But before moving pip outdated to pip list --outdated I would love that a core dev reviews my patch.

I have two concerns about it:

• Performance: PackageFinder.find_requirement is slow, there should be a way to create a batch of queries, to speed things up or maybe using threads.
• That method returns a Link, that I think is always pointing to a PyPI url, right? So how should I proceed with packages installed from version control repositories.

Here is the last version of pip outdated:
https://github.com/maraujop/pip/blob/develop/pip/commands/outdated.py

Thanks, regards
Miguel

[jezdez]

@maraujop Thanks for the work, regarding your questions:

• Yeah, extending PackageFinder.find_requirement or even replacing it with a saner implementation seems like a good idea. The distutils2 project might have a better implementation of the requirement discovery, not sure though.
• Editable requirements (from VCS) shouldn't be covered by the --outdated flag for now (due to the fact that defining "outdated" for a specific VCS checkout is impossible).

[carljm]

Hi Miguel - your code looks good to me in general. I know find_requirement might be slow, but I think we're better off doing this in stages; I don't want to hold up the feature for some kind of massive performance optimization or reorganization of find_requirement.

I agree with @jezdez that the --outdated flag should not return editable requirements. And I also agree that list is a good command name, and I like the proposed flags for it (although for consistency with other places, --local should mean "exclude packages outside the current virtualenv", not "non-editable packages").

[ogirardot]

btw just for the record the yolk tool has this kind of feature with

yolk -U, --show-updates  Check PyPI for updates on package(s).

[pnasrat]

@maraujop have you had time to address the concerns of @jezdez and @carljm re --outdated and flag consistency?

[lepture]

When should this be merged ? If it will not be merged, please close it.

It has been one year since this pull request. But this feature is still not included in pip.

😭

[jezdez]

@lepture It'll be merged when the code is ready, which takes a while sometimes.

[pnasrat]

@maraujop any updates?

[xster]

it's been over a year... let's put it in :)

[maraujop]

Sorry, to take so long to answer. I planned back in time to address to move the code to a list command, but for some reason or other I didn't tackle it, although it shouldn't be much work. I would love to finish it, but I'm currently overwhelmed with work and organizing some Python events in Spain, so I'm not sure when I will have the time, sorry for the inconvenience.

Cheers,
Miguel

[qwcode]

this being handled by pull #675