[Feature Request] new rule that enforces expressing dependencies as ~= or == (no >=)

[alainsanguinetti]

Hi there, thanks a lot of for this tool! Something I've discussed with a colleague. What are your thoughts on this?

Is your feature request related to a problem? Please describe.

When a project uses >= to express dependencies, this can lead to unpredictable outcomes far in the future, for example when used in combination with a docker image, that would after a while be regenerated, and then would take in a new major release of a dependency, that breaks the system actually

Describe the solution you would like

a new rule that checks that in the dependencies, only == or ~= is used, and no >=

Additional context

I can help with the code

[timofey-ai71]

Chiming in with detailed https://iscinumpy.dev/post/bound-version-constraints/ arguing for exact opposite approach, proposing >= over pins and upper bounds as a default.

[alainsanguinetti]

Interesting comment!The point i think is to have a single strategy .. and to enforce it ! On 9 Aug 2025, at 21:08, Timofey Urbanovich @.***> wrote:timofey-ai71 left a comment (fpgmaas/deptry#1164) Chiming in with detailed https://iscinumpy.dev/post/bound-version-constraints/ arguing for exact opposite approach, proposing >= over pins and upper bounds as a default.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[mkniewallner]

Chiming in with detailed https://iscinumpy.dev/post/bound-version-constraints/ arguing for exact opposite approach, proposing >= over pins and upper bounds as a default.

For libraries yeah, it definitely makes sense to not have upper bounds, or at the very least to not pin a specific version in order to avoid version incompatibilities between libraries requesting the same dependency.

For projects that are not meant to be distributed as libraries (e.g., a Python web service), pinning exact versions with == is usually recommended (even if having lock files nowadays prevent surprising updates, but pinning still allows more traceability into what is updated, especially when using a tool that automates dependency updates).

So I think that a rule that enforces using == for instance could make sense, but since it would mostly apply to non-library projects, it should probably be something opt-in, as otherwise users of deptry that use it in libraries will have false positives and need to ignore the rule. Though even for libraries, IMO this rule could still be useful for development dependencies since those are not part of the package distribution, so it would make sense to recommend pinning to exact versions.

Maybe an option that indicates if the project is meant to be "distributed" or not could make sense to have, since based on that we could enable the rule by default and for instance:

• require using == for all dependencies if the project is not a library
• require using == only for dev dependencies if the project is a library

I'll probably give a shot at this later, as I know I'd be interested in having such a rule myself, but wasn't sure if this would be something that should be handled by deptry or part of other tools.