starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-13 22:03:32 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Document process for persisting optional packages across virtual environment rebuilds #3444

New Issue
Closed
opened 2025-12-29 18:29:11 +01:00 by adam · 6 comments
adam commented 2025-12-29 18:29:11 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Mar 6, 2020).

Change Type

[x] Addition
[ ] Correction
[ ] Deprecation
[ ] Cleanup (formatting, typos, etc.)

Area

[x] Installation instructions
[ ] Configuration parameters
[ ] Functionality/features
[ ] REST API
[ ] Administration/development
[ ] Other

Proposed Changes

The v2.7.9 release introduced a new install procedure, where NetBox is installed within a Python virtual environment. On upgrade, this virtual environment is torn down and rebuilt, and all required packages are reinstalled. This ensures that all required dependencies are of the correct version while avoiding pip conflicts.

However, this does not account for optional packages which may have been installed, such as napalm or django-storages. We need a mechanism for users to track the existence of these additional packages to ensure that they too are reinstalled during an upgrade.

(The resolution here may extend beyond mere documentation, but I have opened this as a documentation issue as it seemed to fit best.)

Originally created by @jeremystretch on GitHub (Mar 6, 2020). ### Change Type [x] Addition [ ] Correction [ ] Deprecation [ ] Cleanup (formatting, typos, etc.) ### Area [x] Installation instructions [ ] Configuration parameters [ ] Functionality/features [ ] REST API [ ] Administration/development [ ] Other ### Proposed Changes The v2.7.9 release introduced a new install procedure, where NetBox is installed within a Python virtual environment. On upgrade, this virtual environment is torn down and rebuilt, and all required packages are reinstalled. This ensures that all required dependencies are of the correct version while avoiding pip conflicts. However, this does not account for optional packages which may have been installed, such as `napalm` or `django-storages`. We need a mechanism for users to track the existence of these additional packages to ensure that they too are reinstalled during an upgrade. (The resolution here may extend beyond mere documentation, but I have opened this as a documentation issue as it seemed to fit best.)
adam added the status: acceptedtype: documentation labels 2025-12-29 18:29:11 +01:00
adam closed this issue 2025-12-29 18:29:11 +01:00
adam commented 2025-12-29 18:29:11 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 6, 2020):

IMO the best solution here is to designate a particular file, e.g. local_requirements, for the enumeration of any optional packages that need to be reinstalled. The upgrade script will check for this file and, if it exists, make a second call to pip: pip3 install -r local_requirements.txt.

Open to other suggestions, though.

@jeremystretch commented on GitHub (Mar 6, 2020): IMO the best solution here is to designate a particular file, e.g. `local_requirements`, for the enumeration of any optional packages that need to be reinstalled. The upgrade script will check for this file and, if it exists, make a second call to pip: `pip3 install -r local_requirements.txt`. Open to other suggestions, though.
adam commented 2025-12-29 18:29:11 +01:00
Author
Owner
Copy Link

@dstarner commented on GitHub (Mar 7, 2020):

Yea the two options I could see are either have pip freeze > local_requirements.txt and then load it if present, or just add --options to the install script like napalm-enabled, --ldap-enabled, storage-enabled

@dstarner commented on GitHub (Mar 7, 2020): Yea the two options I could see are either have `pip freeze > local_requirements.txt` and then load it if present, or just add `--options` to the install script like `napalm-enabled`, `--ldap-enabled`, `storage-enabled`
adam commented 2025-12-29 18:29:12 +01:00
Author
Owner
Copy Link

@fourstone commented on GitHub (Mar 9, 2020):

why not just go with jeremys suggestion:

requirements.txt (delivered)
requirements_local.txt (locally edited and static, i.e. not touched by the upgrade)

During upgrade both files are used to pull their components.

imho simple and clean.

PS: This kind of change would better fit into a major release, not really in a minor revision.

@fourstone commented on GitHub (Mar 9, 2020): why not just go with jeremys suggestion: requirements.txt (delivered) requirements_local.txt (locally edited and static, i.e. not touched by the upgrade) During upgrade both files are used to pull their components. imho simple and clean. PS: This kind of change would better fit into a major release, not really in a minor revision.
adam commented 2025-12-29 18:29:12 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 9, 2020):

PS: This kind of change would better fit into a major release, not really in a minor revision.

As I've explained on the discussion list, NetBox versioning implies changes (or the lack thereof) to NetBox's API, major features, and integrations. It has no bearing on routine tasks relating to systems administration. As with every release, it's important to read the release notes prior to upgrading.

@jeremystretch commented on GitHub (Mar 9, 2020): > PS: This kind of change would better fit into a major release, not really in a minor revision. As I've explained on the discussion list, NetBox versioning implies changes (or the lack thereof) to NetBox's API, major features, and integrations. It has no bearing on routine tasks relating to systems administration. As with every release, it's important to read the release notes prior to upgrading.
adam commented 2025-12-29 18:29:12 +01:00
Author
Owner
Copy Link

@fourstone commented on GitHub (Mar 10, 2020):

most software projects differentiate between minor changes which are always permissible and architectural or otherwise groundbreaking changes only permissible in major revision numbers. They do this because it was proven to be good for everybody.

What I am trying to say: If you have such a change as now, why not
a: wait until a few such things come together and make a major revision
b: do it now and just give it a major number so everybody is prewarned.

thanks, Martin

@fourstone commented on GitHub (Mar 10, 2020): most software projects differentiate between minor changes which are always permissible and architectural or otherwise groundbreaking changes only permissible in major revision numbers. They do this because it was proven to be good for everybody. What I am trying to say: If you have such a change as now, why not a: wait until a few such things come together and make a major revision b: do it now and just give it a major number so everybody is prewarned. thanks, Martin
adam commented 2025-12-29 18:29:12 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 10, 2020):

This issue is closed. Please see the discussion on the mailing list.

@jeremystretch commented on GitHub (Mar 10, 2020): This issue is closed. Please see the discussion on the mailing list.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub 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
No Label status: accepted type: documentation
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#3444
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?