consider relaxing version locks in requirements.txt #2445

Closed
opened 2025-12-29 18:18:55 +01:00 by adam · 1 comment
Owner

Originally created by @williamh on GitHub (Mar 6, 2019).

Hello.

I am a packager for Gentoo Linux, and I have been asked to package this software.

In looking over the software, I noticed that you have '==' and '<' version locks in requirements.txt.
Unfortunately, these types of version locks make it extremely difficult to package software since there will inevitably be conflicts between software packages with different dependencies.

I'm curious why you use these types of version locks -- are there specific incompatibilities with other versions? Can you relax these version locks (e.g. make them >= instead of ==) and remove the '<' version lock? If not, can I treat them all as >= in our packaging.

Thanks much,

William

Originally created by @williamh on GitHub (Mar 6, 2019). Hello. I am a packager for Gentoo Linux, and I have been asked to package this software. In looking over the software, I noticed that you have '==' and '<' version locks in requirements.txt. Unfortunately, these types of version locks make it extremely difficult to package software since there will inevitably be conflicts between software packages with different dependencies. I'm curious why you use these types of version locks -- are there specific incompatibilities with other versions? Can you relax these version locks (e.g. make them >= instead of ==) and remove the '<' version lock? If not, can I treat them all as >= in our packaging. Thanks much, William
adam closed this issue 2025-12-29 18:18:55 +01:00
Author
Owner

@jeremystretch commented on GitHub (Mar 7, 2019):

Unfortunately we've had issues with even patch updates in dependencies introducing backward-incompatible changes. Aside from Django, we pin all dependencies to a known good release until NetBox's next minor version bump.

If a user requires alternate versions of required packages installed, the conventional advice is to install NetBox within a Python virtual environment (which isn't a bad idea anyway). I'm not sure whether that's an option you have.

It's up to you however you'd like to approach this, but I feel obligated to mention two points:

  1. NetBox is under heavy development and releases are fairly frequent: on the order of 2-3 weeks, typically.
  2. We can't accept bug reports relating to installation issues outside of our control (e.g. distro or container-based packaging).

I'm going to close this issue out but please feel free to continue the discussion on our mailing list if you'd like. Thanks!

@jeremystretch commented on GitHub (Mar 7, 2019): Unfortunately we've had issues with even patch updates in dependencies introducing backward-incompatible changes. Aside from Django, we pin all dependencies to a known good release until NetBox's next minor version bump. If a user requires alternate versions of required packages installed, the conventional advice is to install NetBox within a Python virtual environment (which isn't a bad idea anyway). I'm not sure whether that's an option you have. It's up to you however you'd like to approach this, but I feel obligated to mention two points: 1. NetBox is under heavy development and releases are fairly frequent: on the order of 2-3 weeks, typically. 2. We can't accept bug reports relating to installation issues outside of our control (e.g. distro or container-based packaging). I'm going to close this issue out but please feel free to continue the discussion on our [mailing list](https://groups.google.com/forum/#!forum/netbox-discuss) if you'd like. Thanks!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#2445