Required dependencies are pinned to old exact versions - please loosen or refresh them

[oakhan3]

Describe the bug
Several of Chepy's dependencies are pinned to exact versions that are significantly out of date. This causes dependency conflicts when installing Chepy alongside other packages, and in some cases exposes users to known security vulnerabilities (notably PyJWT==1.7.1, released December 2018, which predates several CVEs in the 1.x line).

Package	Pinned Version	Released	PyPI URL
emoji	2.0.0	Jul 16, 2022	https://pypi.org/project/emoji/2.0.0/
fire	0.7.1	Aug 16, 2025	https://pypi.org/project/fire/0.7.1/
jmespath	1.0.1	Jun 17, 2022	https://pypi.org/project/jmespath/1.0.1/
lz4	4.3.2	Dec 30, 2022	https://pypi.org/project/lz4/4.3.2/
msgpack	1.0.4	Jun 3, 2022	https://pypi.org/project/msgpack/1.0.4/
parsel	1.9.1	Apr 8, 2024	https://pypi.org/project/parsel/1.9.1/
passlib	1.7.4	Oct 8, 2020	https://pypi.org/project/passlib/1.7.4/
PGPy	0.6.0	Nov 24, 2022	https://pypi.org/project/PGPy/0.6.0/
pretty-errors	1.2.25	Nov 24, 2021	https://pypi.org/project/pretty-errors/1.2.25/
PyJWT	1.7.1	Dec 7, 2018	https://pypi.org/project/PyJWT/1.7.1/
pyOpenSSL	23.2.0	May 31, 2023	https://pypi.org/project/pyOpenSSL/23.2.0/

Expected behavior
Dependencies should use minimum version specifiers (e.g. pyjwt>=2.0.0) or at minimum a compatible release range (e.g. pyjwt~=2.8) rather than exact pins (==), unless there is a specific known incompatibility with newer versions. This allows pip to resolve a compatible set of packages without conflicts and keeps users on maintained, patched versions of dependencies.

Additional context
PyJWT==1.7.1 is of particular concern - the 1.x branch is unmaintained and has known vulnerabilities. The 2.x line has been stable since 2021. It would be worth either bumping to pyjwt>=2.0.0 or auditing whether the 1.x API surface is still required.

More broadly, using exact pins in install_requires (as opposed to a lockfile like requirements.txt) is generally considered an anti-pattern for libraries, as it makes Chepy difficult to use as a dependency in larger projects.

[securisec]

Noted, as dependency management could be improved and it is a work item for me at the moment. For version 8.0, the goal is to move to more modern dependency management solutions like lockfiles.

The challenge is that using certain dependencies like pyjwt and pyopenssl is intentional as newer version of those dependencies will not support certain capabilities like signing hs256 tokens with rs256 keys.

Saying that, I will work with the problematic deps and see what can be upgraded without breaking and will consider for the next major release what functionality can be removed.

[securisec]

5 of the deps listed has been updated, some are already at their latest, pyopenssl and pyjwt at this time cannot be updated due to breaking functionality. Tagging issue for v8 release where the goal is to move to newer ways of installing python packages.

[oakhan3]

Thank you for the quick response, if there is anything I can help with please let me know, my main concern by far is pyJWT.

As I understand it, the breaking change is expected per the security fixes from pyJWT, in this particular case could we upgrade pyJWT and use it for all operations except signing hs256 tokens with rs256 keys - for that could we leverage cryptography? (lower level lib which will allot more freedom in use for this warranted use case)

[securisec]

Of course. For now, i have released 7.5.1 with some of the updated deps. For now, really it will be a matter of moving on to pyproject which will require a bit of lift and then use updated deps to see what breaks and what can be refactored. But I will track the issue and will reach out if I need help. Thanks for the offer!