mirror of
https://github.com/netbox-community/netbox.git
synced 2026-01-11 21:10:29 +01:00
requirements.txt should specify redis version #2835
Closed
opened 2025-12-29 18:22:37 +01:00 by adam
·
16 comments
No Branch/Tag Specified
main
update-changelog-comments-docs
feature-removal-issue-type
20911-dropdown
20239-plugin-menu-classes-mutable-state
21097-graphql-id-lookups
feature
fix_module_substitution
20923-dcim-templates
20044-elevation-stuck-lightmode
feature-ip-prefix-link
v4.5-beta1-release
20068-import-moduletype-attrs
20766-fix-german-translation-code-literals
20378-del-script
7604-filter-modifiers-v3
circuit-swap
12318-case-insensitive-uniqueness
20637-improve-device-q-filter
20660-script-load
19724-graphql
20614-update-ruff
14884-script
02496-max-page
19720-macaddress-interface-generic-relation
19408-circuit-terminations-export-templates
20203-openapi-check
fix-19669-api-image-download
7604-filter-modifiers
19275-fixes-interface-bulk-edit
fix-17794-get_field_value_return_list
11507-show-aggregate-and-rir-on-api
9583-add_column_specific_search_field_to_tables
v4.5.0
v4.4.10
v4.4.9
v4.5.0-beta1
v4.4.8
v4.4.7
v4.4.6
v4.4.5
v4.4.4
v4.4.3
v4.4.2
v4.4.1
v4.4.0
v4.3.7
v4.4.0-beta1
v4.3.6
v4.3.5
v4.3.4
v4.3.3
v4.3.2
v4.3.1
v4.3.0
v4.2.9
v4.3.0-beta2
v4.2.8
v4.3.0-beta1
v4.2.7
v4.2.6
v4.2.5
v4.2.4
v4.2.3
v4.2.2
v4.2.1
v4.2.0
v4.1.11
v4.1.10
v4.1.9
v4.1.8
v4.2-beta1
v4.1.7
v4.1.6
v4.1.5
v4.1.4
v4.1.3
v4.1.2
v4.1.1
v4.1.0
v4.0.11
v4.0.10
v4.0.9
v4.1-beta1
v4.0.8
v4.0.7
v4.0.6
v4.0.5
v4.0.3
v4.0.2
v4.0.1
v4.0.0
v3.7.8
v3.7.7
v4.0-beta2
v3.7.6
v3.7.5
v4.0-beta1
v3.7.4
v3.7.3
v3.7.2
v3.7.1
v3.7.0
v3.6.9
v3.6.8
v3.6.7
v3.7-beta1
v3.6.6
v3.6.5
v3.6.4
v3.6.3
v3.6.2
v3.6.1
v3.6.0
v3.5.9
v3.6-beta2
v3.5.8
v3.6-beta1
v3.5.7
v3.5.6
v3.5.5
v3.5.4
v3.5.3
v3.5.2
v3.5.1
v3.5.0
v3.4.10
v3.4.9
v3.5-beta2
v3.4.8
v3.5-beta1
v3.4.7
v3.4.6
v3.4.5
v3.4.4
v3.4.3
v3.4.2
v3.4.1
v3.4.0
v3.3.10
v3.3.9
v3.4-beta1
v3.3.8
v3.3.7
v3.3.6
v3.3.5
v3.3.4
v3.3.3
v3.3.2
v3.3.1
v3.3.0
v3.2.9
v3.2.8
v3.3-beta2
v3.2.7
v3.3-beta1
v3.2.6
v3.2.5
v3.2.4
v3.2.3
v3.2.2
v3.2.1
v3.2.0
v3.1.11
v3.1.10
v3.2-beta2
v3.1.9
v3.2-beta1
v3.1.8
v3.1.7
v3.1.6
v3.1.5
v3.1.4
v3.1.3
v3.1.2
v3.1.1
v3.1.0
v3.0.12
v3.0.11
v3.0.10
v3.1-beta1
v3.0.9
v3.0.8
v3.0.7
v3.0.6
v3.0.5
v3.0.4
v3.0.3
v3.0.2
v3.0.1
v3.0.0
v2.11.12
v3.0-beta2
v2.11.11
v2.11.10
v3.0-beta1
v2.11.9
v2.11.8
v2.11.7
v2.11.6
v2.11.5
v2.11.4
v2.11.3
v2.11.2
v2.11.1
v2.11.0
v2.10.10
v2.10.9
v2.11-beta1
v2.10.8
v2.10.7
v2.10.6
v2.10.5
v2.10.4
v2.10.3
v2.10.2
v2.10.1
v2.10.0
v2.9.11
v2.10-beta2
v2.9.10
v2.10-beta1
v2.9.9
v2.9.8
v2.9.7
v2.9.6
v2.9.5
v2.9.4
v2.9.3
v2.9.2
v2.9.1
v2.9.0
v2.9-beta2
v2.8.9
v2.9-beta1
v2.8.8
v2.8.7
v2.8.6
v2.8.5
v2.8.4
v2.8.3
v2.8.2
v2.8.1
v2.8.0
v2.7.12
v2.7.11
v2.7.10
v2.7.9
v2.7.8
v2.7.7
v2.7.6
v2.7.5
v2.7.4
v2.7.3
v2.7.2
v2.7.1
v2.7.0
v2.6.12
v2.6.11
v2.6.10
v2.6.9
v2.7-beta1
Solcon-2020-01-06
v2.6.8
v2.6.7
v2.6.6
v2.6.5
v2.6.4
v2.6.3
v2.6.2
v2.6.1
v2.6.0
v2.5.13
v2.5.12
v2.6-beta1
v2.5.11
v2.5.10
v2.5.9
v2.5.8
v2.5.7
v2.5.6
v2.5.5
v2.5.4
v2.5.3
v2.5.2
v2.5.1
v2.5.0
v2.4.9
v2.5-beta2
v2.4.8
v2.5-beta1
v2.4.7
v2.4.6
v2.4.5
v2.4.4
v2.4.3
v2.4.2
v2.4.1
v2.4.0
v2.3.7
v2.4-beta1
v2.3.6
v2.3.5
v2.3.4
v2.3.3
v2.3.2
v2.3.1
v2.3.0
v2.2.10
v2.3-beta2
v2.2.9
v2.3-beta1
v2.2.8
v2.2.7
v2.2.6
v2.2.5
v2.2.4
v2.2.3
v2.2.2
v2.2.1
v2.2.0
v2.1.6
v2.2-beta2
v2.1.5
v2.2-beta1
v2.1.4
v2.1.3
v2.1.2
v2.1.1
v2.1.0
v2.0.10
v2.1-beta1
v2.0.9
v2.0.8
v2.0.7
v2.0.6
v2.0.5
v2.0.4
v2.0.3
v2.0.2
v2.0.1
v2.0.0
v2.0-beta3
v1.9.6
v1.9.5
v2.0-beta2
v1.9.4-r1
v1.9.3
v2.0-beta1
v1.9.2
v1.9.1
v1.9.0-r1
v1.8.4
v1.8.3
v1.8.2
v1.8.1
v1.8.0
v1.7.3
v1.7.2-r1
v1.7.1
v1.7.0
v1.6.3
v1.6.2-r1
v1.6.1-r1
1.6.1
v1.6.0
v1.5.2
v1.5.1
v1.5.0
v1.4.2
v1.4.1
v1.4.0
v1.3.2
v1.3.1
v1.3.0
v1.2.2
v1.2.1
v1.2.0
v1.1.0
v1.0.7-r1
v1.0.7
v1.0.6
v1.0.5
v1.0.4
v1.0.3-r1
v1.0.3
1.0.0
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
Mirrored from GitHub Pull Request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/netbox#2835
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @candlerb on GitHub (Aug 28, 2019).
Environment
Steps to Reproduce
On upgrading from netbox 2.6.1 to 2.6.2 I observed the following output from
upgrade.sh:Expected Behavior
No errors on upgrade
Observed Behavior
pip3 complains that the currently installed version of redis is not usable, but does not offer to upgrade it.
Given that redis is now a mandatory dependency, I think that requirements.txt should list it, with a specific version. I added this to the end of requirements.txt:
On re-running upgrade.sh, the redis version was updated and no errors were reported.
@jeremystretch commented on GitHub (Aug 28, 2019):
As a rule, we don't list indirect dependencies in
requirements.txtbecause they are redundant. What is preventing pip from upgrading the installedredispackage in this instance?@candlerb commented on GitHub (Aug 28, 2019):
I don't know, but a similar issue was raised 3 months ago on stackoverflow
The affected system is Ubuntu 16.04, and has pip version 19.0.2 (newer than the 8.1.1 supplied by default, but older than the latest 19.2.3)
Trying to reproduce in a fresh Ubuntu 16.04 lxd container:
But this is successful!
So I suspect it's something to do with recursive dependencies, or two different packages specifying different redis dependencies.
FWIW, here is the complete log of the original failed upgrade, while it's still in my terminal buffer.
AFAICS, django-rq's requirements are defined in setup.py:
@candlerb commented on GitHub (Aug 28, 2019):
OK, I think I have it.
The following sequence reproduces it:
where r.txt contains:
(those are two lines out of Netbox's requirements.txt)
Result:
@candlerb commented on GitHub (Aug 28, 2019):
In case it's helpful, there's a pip3 check command which can test for this condition.
@candlerb commented on GitHub (Sep 8, 2019):
@jeremystretch wrote:
To summarise: this is a known issue with pip, which does not implement dependency resolution properly. Specifically: "'first found wins' behavior for dependency requirements/constraints, which results in not respecting all constraints"
The suggested workaround is "specifying the constraints for the dependency on the top level", which is what I proposed.
@kobayashi commented on GitHub (Sep 28, 2019):
Thanks to your suggestion for this issue.
IMO, requirements.txt should be the list of dependencies for "this package" without nested dependencies. If dependencies' dependencies are included in requirements.txt, it make unclear the content. Also the file will have to continue to follow up the nested dependencies.
@candlerb commented on GitHub (Sep 28, 2019):
To summarise, the problem is:
The solution given here is to make A depend on D >= 2 explicitly. This has been the situation since 2013.
Do you have a different solution?
@candlerb commented on GitHub (Sep 28, 2019):
Note: the official documentation for pip says the same explicitly about requirements.txt:
Alternatively, you could put this in a separate constraints file if you wish to keep it out of requirements.txt
@kobayashi commented on GitHub (Sep 29, 2019):
This happens only some upgrading situation if redis<3, so how about including simple redis version cehcker in upgrade.sh file to prevent this case?
django-rq 2.1.0 has requirement redis>=3so like this
@candlerb commented on GitHub (Sep 29, 2019):
I guess that will work - just seems a lot messier to me than adding one line to requirements.txt (plus a comment explaining why it's there) which is the official way of dealing with this problem
@kobayashi commented on GitHub (Oct 1, 2019):
Yeah, that's true and pip docs describes for sub dependencies as you said.
Let me think about this case again. This happens only when upgrading for the users installed redis version < 3, right? Even if an user install v2.6.1 right now then upgrade to v2.6.2, that will not happen because netbox v2.6.1 requires django-rq v2.1.0 which already requires redis version >=3. I tried that. So this is the special case.
@jeremystretch, you told us no duplication in the requirements.txt. how do you think about this case.
@candlerb commented on GitHub (Oct 1, 2019):
That's not exactly the reason.
django-cacheops depends on redis>=2.9.1, and django-rq depends on redis>=3. pip is broken, so it only attempts to meet the first requirement seen (redis>=2.9.1).
However, if redis is not currently installed, the
>=requirement means that pip installs the latest version available, which happens to meet both requirements.@jeremystretch commented on GitHub (Oct 1, 2019):
I get what you're saying, but this seems pretty clearly outside the scope of NetBox to address. We can't assume the burden for tracking dependencies of dependencies. Literally every project which utilizes pip will run into this sort of issue if it's a bug in pip. It also seems like a fairly niche case, and doesn't occur on new installations (or at least I haven't run into it).
@candlerb commented on GitHub (Oct 1, 2019):
Well, it did happen to me, and I had to spend time working out why it was broken. I do understand why you don't want to trace the dependency tree to put the necessary dependencies in requirements.txt.
You could just add something like this to
upgrade.sh:@kobayashi commented on GitHub (Oct 5, 2019):
I think this is good idea to run
pip checkin upgrade.sh. This may prevent for a similar case in the future not only for this case.@kobayashi commented on GitHub (Oct 16, 2019):
pip3 checkapproach is accepted. Can you make PR for this? @candlerb