search

pyupio / safety

Safety checks Python dependencies for known security vulnerabilities and suggests the proper remediations for vulnerabilities detected.
https://safetycli.com/product/safety-cli
MIT License
1.66k stars 141 forks source link

safety packaging dependency conflicts with packages that require newer version of packaging #455

Open rktoomey opened 1 year ago

rktoomey commented 1 year ago

Description

The changelog for release 2.34 says the issue with packaging 22.0 is fixed: https://github.com/pyupio/safety/blob/d8bd6f7baefba3db6dcdef8f5a2750da15150106/CHANGELOG.md#234---2022-12-07 https://github.com/pyupio/safety/pull/439

However, in 2.3.5 packaging was then fixed to a compatible range being < 22.0: https://github.com/pyupio/safety/commit/aa1b1532818a1b2cb229b14907cad64c927fa8c6

I noticed this when I was updating dependencies and had a version conflict caused by newer packages requiring packaging

Because no versions of safety match >2.3.5,<3.0.0
 and safety (2.3.5) depends on packaging (>=21.0,<22.0), safety (>=2.3.5,<3.0.0) requires packaging (>=21.0,<22.0).
And because black (23.1.0) depends on packaging (>=22.0)
 and no versions of black match >23.1.0,<24.0.0, safety (>=2.3.5,<3.0.0) is incompatible with black (>=23.1.0,<24.0.0).

What I Did

Temporarily reverted the packages with a conflict and pinned them to an earlier version.

yeisonvargasf commented 1 year ago

Hi @rktoomey, 2.3.4 fixed the issue temporarily; in the coming days, a new version with multiple improvements will resolve the dependency issue you are reporting.

kevinbowen777 commented 1 year ago

Is there any update on the release of 2.3.6?

yeisonvargasf commented 1 year ago

@kevinbowen777, we will release 2.4.0 as a beta with many improvements and a fix for this issue. The release will happen this week.

kevinbowen777 commented 1 year ago

Thank you. I'm looking forward to testing the new release.

snazy commented 1 year ago

@yeisonvargasf do you have any update on the safety release?

yeisonvargasf commented 1 year ago

Hi @rktoomey, @kevinbowen777, and @snazy, thanks for your patience here; we released a beta version (Feb 26) with significant changes and additional improvements.

This version ( https://pypi.org/project/safety/2.4.0b1/) should fix this issue. Could you try?

Let me know if this version works for you.

kevinbowen777 commented 1 year ago

Thanks for the beta release. I've been running it successfully against a couple of my repos and it looks good so far. This version also appears to fail properly with the insecure-package installed.

snazy commented 1 year ago

LGTM (our build's passing w/ 2.4.0b1 + the currently blocked tox + black version bumps)

snazy commented 1 year ago

Hi @yeisonvargasf, do you have an update when 2.4.0 will be released?

rktoomey commented 1 year ago

Hi, @yeisonvargasf, sorry for the delay.

I just tested my build with 2.4.0b1 and it works great. Thanks for working to get this fixed! Looking forward to the release :)

andy-maier commented 1 year ago

We also had this issue with the pinning of "packaging", and tested safety 2.3.4 and 2.4.0b1 with packaging 22.0, 23.0 and 23.1 (on Python 3.9) and it all worked fine.

It turns out safety 2.4.0b1 pins packaging to <=23.0 which is in conflict with tox>=4.0 which requires packaging>=23.1

Can you not just remove the pinning for the "packaging" package completely, like it was in safety 2.3.4 and earlier? Pinning a dependent package is always prone to cause conflicts for someone out there, and you should find any incompatibilities with that package in your tests.

Right now, we solve these conflicts by excluding safety 2.3.5.

yeisonvargasf commented 11 months ago

Hi, @andy-maier agree about the problem with pinning; the pinning was a quick fix as we are under a significant revamp of Safety CLI, which right now is in a closed beta phase for version 3.0

In the coming month, we'll revamp our CI/CD pipelines to catch these issues and release quicker new features and bug fixes. We should have a better changelog, contribute guides, and better PR checks.

Also, as a comment, PyUp is in a rebranding journey, so hoping you all see soon the changes we are working on.

wkoot commented 6 months ago

What's the status on a new version release? Is it an option to release 2.4.0 before 3.0, or perhaps even a 2.3.6 bugfix? It would be nice to avoid this error with an unbound upper-version as on main branch. Also, why not move all content of setup.cfg and test_requirements.txt to pyproject.toml?