How can I update indirect dependencies?

[ikanago]

I have received security alert to upgrade pillow to 9.0.1 in the project I belong to.
In the project, pillow is an indirect dependency installed as a dependency of matplotlib=3.5.1.
According to poetry.lock, I have pillow=8.4.0, which is vulnerable version.
So how do I update pillow to 9.0.1 or higher?

Thanks.

[abn]

Since matplotlib defines it as a lower bound constraint, a simple poetry update should do the trick unless something else depends on it too.

Alternatively if you want to explicitly say you want a minimum version of pillow, you can add it via poetry add to your project's main or development dependencies. The former will impact your packaged wheel's metadata, the latter will only impact the lockfile and environments managed by Poetry.

[ikanago]

Thank you for your quick answer!
I checked poetry.lock once more, and I found another package depending on pillow=^8.3.2, which prevents pillow from being upgraded to 9.0.1.
The package is developed by our team, so upgrading pillow in the package will be done without problem.

[AdamJel]

@abn hello, I have a follow-up question. I initially posted it on discord. The origin of my question is mostly the same - I need a dependency graph pinned as much as possible for my prod env, but be able to update (preferably on patch level only) due to safety (bandit complaining about version with known vulnerabilities).

IMO the proposed solution is just a workaround and not a good one. Consider a scenario, when matplotlib changes its dependency from pillow to an alternative package. Then, when pillow was added as a 1st order dependency (directly to pyproject.toml file), this change will cause two thing: 1) pillow will NOT be needed, but will be present in dependencies (secretively - this will never be found out) and 2) matplotlibs new dependency will be added without any version constraint, so the original situation may reoccur.

How do remedy such scenarios?

I think, something like poetry update --patch-only would be highly useful. But it needs to affect all dependencies, not only direct ones but implicit ones as well.

[abn]

The recommendation is to simply update unless the project itself wants a minumum version. The latter implies that the it is managed by/for the project in question. In that scenario, the appropriate thing to do, I'd say, is to define a top level dependency rather than depending on an implicit nested dependency.

As for your feature request, I can see there being feature where locked dependency updates are selected based on a constraint like patch level only. Unsure about how this will impact non-semver PEP440 versions though. Feel free to raise a new discussion/feature request to discuss that. I'd be interested to hear what the community thinks about this. In the meantime, you can achieve something similar by using a using a PyPI proxy with some allow-listing (think nexus provides this iirc) and ensuring your projects use that as the primary and default repository.

[AdamJel]

Thanks. I raised a general question about it here #5545