How do I find outdated dependencies?

[WhyNotHugo]

• I have searched the issues of this repo and believe that this is not a duplicate.

Issue

I've a large project with ~32 pinned dependencies.

poetry update is good for updating within the constraints of these project.

However, I want to find which dependencies are out of date. E.g.: list all dependencies for which I've pinned a specific version, but has newer releases.

I try to proactively keep my deps up to date, but so far I've been manually checking in pypi if each one has a new version. How can I figure out this using poetry?

[sdispater]

You can use the poetry show command with the --outdated/-o option:

poetry show -o

For more information, you can check out the documentation: https://python-poetry.org/docs/cli/#show

[levrik]

@sdispater Is there a way to filter this to top-level dependencies only? Without this the option is quite useless for me.

[WhyNotHugo]

Is this issue a WONTFIX?

This is becoming super annoying to deal with manually, especially for large projects.

[SamuelMS]

@abn I agree here – we generally only care about our project-specific top-level dependencies, not stuff five layers deep. poetry show -o is really noisy for large projects.

[vertti]

It seems crazy that the default isn't just showing the outdated top-level dependencies. That is usually the only thing that a project has control over and/or should mess with. So why, by default, show a lot of unnecessary info mixed in?

[sinoroc]

From my point of view...

When talking about dependencies, there are 2 cases:

• either you are working on an application, that should be installed in isolation (so you can control all requirements in the virtual environment), in which case all dependencies matter, you may want total control and pin everything.
• or you are working on a library, that should be installed alongside other libraries and the parent application, in which case you only want to specify version ranges of the direct top-level dependencies of your own library.

So from my point of view, if you care about outdated dependencies then you are most likely in the first case and so you should care about all dependencies not only the top-level ones.

[SamuelMS]

either you are working on an application, that should be installed in isolation (so you can control all requirements in the virtual environment), in which case all dependencies matter, you may want total control and pin everything.

I think this is rather pedantic. In my experience, most developers don't care about second- or third-level dependencies – just the top-level dependencies that their application directly relies on – in the same way that they don't think about OS-level dependencies (i.e. what version of g++ is installed, or even Python).

We use automated code-/dependency-scanning tools (HP Fortify, Whitesource, Snyk, etc) to look for CVEs, license or breaking changes, etc – and these are helpful for monitoring dependencies deeper down the stack, both in and outside of Python. These tools go hand-in-hand with the current default behavior of the show command.

Still, it would be very helpful to help developers filter out the noise and be able to ask "which of the stuff that I installed directly (read: listed in pyproject.toml) has new versions available?" – this seems like a pretty natural feature to have.

@sdispater Can you reconsider and re-open this?

[ruohola]

poetry show --outdated | grep --file=<(poetry show --tree | grep '^\w' | cut -d' ' -f1)

seems to work okishly to only show outdated top-level dependencies.

[plazmakeks]

Following the approach by @ruohola I noticed flake8 has a dependency called mccabe which notes flake8 in its description and would be returned by the upper solution. To avoid this i'm using this one now:

poetry show --outdated | grep -P "^($(poetry show --tree | grep '^\w' | cut -d' ' -f1 | paste -s -d"|" -))"