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

[rktoomey]

• safety version: 2.3.5
• Python version: 3.10
• Operating System: Linux

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
#439

However, in 2.3.5 packaging was then fixed to a compatible range being < 22.0:
aa1b153

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]

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]

Is there any update on the release of 2.3.6?

[yeisonvargasf]

@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]

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

[snazy]

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

[yeisonvargasf]

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]

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]

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

[snazy]

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

[rktoomey]

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]

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]

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]

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?