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?

[dylanpulver]

Hi @rktoomey and everyone involved,

Thank you for your patience and for bringing this to our attention.

We understand the challenges caused by the dependency conflicts with the packaging library. We are pleased to inform you that Safety version 3 has been released, and it should resolve the conflicts with newer versions of packaging.

However, we recognize that pinning dependency versions can sometimes cause conflicts. To prevent similar issues in the future, we are working on improving our CI/CD pipelines to better test and validate our dependencies.

Please test your environment with the latest version, Safety 3, and let us know if the conflict persists. We are committed to ensuring smoother updates and fewer dependency conflicts moving forward.

Thank you for your continued support and for helping us improve Safety!

Best Regards,
The Safety Team

[wkoot]

The conflict is solved here, tested with latest safety == 3.2.6.

Also, why not move all content of setup.cfg and test_requirements.txt to pyproject.toml?
Now the upper-version pinning remains within test_requirements.txt