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

Allow Plugin to install additional Django App #4058

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

Originally created by @dgarros on GitHub (Sep 1, 2020).

Environment

  • Python version: 2.7.7
  • NetBox version: 2.8.9, 2.9.2

Proposed Functionality

Extend the current plugin model to allow a plugin to install/enable a third party Django Application.

The proposal is to extend the PluginConfig class to support a new django_apps attribute.

class MyPluginConfig(PluginConfig):
    name = "my_plugin"
    verbose_name = "my plugin"
    version = __version__
    base_url = "my_plugin"
    .... 
    django_apps = ["app1", "app2"]

Use Case

As a plugin creator I would like to be able to leverage existing django App.
For example the SAML plugin from @jeremyschulman for netbox netbox-plugin-auth-saml2 is based on django3-auth-saml2. So it’s required to install the other django app independently
there are many existing django app that could be easily reused/extended within NetBox if we could seamlessly install them from a plugin

Database Changes

None

External Dependencies

None

Originally created by @dgarros on GitHub (Sep 1, 2020). ### Environment * Python version: 2.7.7 * NetBox version: 2.8.9, 2.9.2 ### Proposed Functionality Extend the current plugin model to allow a plugin to install/enable a third party Django Application. The proposal is to extend the `PluginConfig` class to support a new `django_apps` attribute. ``` class MyPluginConfig(PluginConfig): name = "my_plugin" verbose_name = "my plugin" version = __version__ base_url = "my_plugin" .... django_apps = ["app1", "app2"] ``` ### Use Case As a plugin creator I would like to be able to leverage existing django App. For example the SAML plugin from @jeremyschulman for netbox netbox-plugin-auth-saml2 is based on django3-auth-saml2. So it’s required to install the other django app independently there are many existing django app that could be easily reused/extended within NetBox if we could seamlessly install them from a plugin ### Database Changes None ### External Dependencies None
adam added the type: featurepending closurestatus: under reviewtopic: plugins labels 2025-12-29 18:32:54 +01:00
adam closed this issue 2025-12-29 18:32:54 +01:00
adam commented 2025-12-29 18:32:54 +01:00
Author
Owner
Copy Link

@cpmills1975 commented on GitHub (Sep 1, 2020):

I support code re-use when it is appropriate to do so, but NetBox needs to be careful that the plugin architecture doesn't start causing plugin bloat due to large numbers of dependencies being installed silently without user interaction. Just look at the Jenkins CI/CD tool for an example of this. Plugin bloat would also make identifying problems with NetBox itself more difficult than it needs to be.

@cpmills1975 commented on GitHub (Sep 1, 2020): I support code re-use when it is appropriate to do so, but NetBox needs to be careful that the plugin architecture doesn't start causing plugin bloat due to large numbers of dependencies being installed silently without user interaction. Just look at the Jenkins CI/CD tool for an example of this. Plugin bloat would also make identifying problems with NetBox itself more difficult than it needs to be.
adam commented 2025-12-29 18:32:54 +01:00
Author
Owner
Copy Link

@kuzmik commented on GitHub (Sep 3, 2020):

I've run into this myself, and I just have a .patch file that I apply to settings.py that adds watchman to INSTALLED_APPS when I build the docker image. Not perfect, but it works for now.

To cpmills point though, I agree that doing this can definitely lead to bloat. Maybe there could be some kind of "I understand that doing this will make things harder to debug" kind of flag or something?

@kuzmik commented on GitHub (Sep 3, 2020): I've run into this myself, and I just have a .patch file that I apply to settings.py that adds watchman to INSTALLED_APPS when I build the docker image. Not perfect, but it works for now. To cpmills point though, I agree that doing this can definitely lead to bloat. Maybe there could be some kind of "I understand that doing this will make things harder to debug" kind of flag or something?
adam commented 2025-12-29 18:32:54 +01:00
Author
Owner
Copy Link

@dgarros commented on GitHub (Sep 4, 2020):

I've been using a similar solution with a .patch method but it's not going to work for a public plugin that is dependent on another Django App.
I think everyone agrees there is a risk associated with python dependencies management but in my opinion this risk is not bigger by introducing this feature. Any plugin can already bring a lot of dependencies and create some packaging issues.

@dgarros commented on GitHub (Sep 4, 2020): I've been using a similar solution with a .patch method but it's not going to work for a public plugin that is dependent on another Django App. I think everyone agrees there is a risk associated with python dependencies management but in my opinion this risk is not bigger by introducing this feature. Any plugin can already bring a lot of dependencies and create some packaging issues.
adam commented 2025-12-29 18:32:54 +01:00
Author
Owner
Copy Link

@lampwins commented on GitHub (Sep 26, 2020):

We mulled this over briefly in the initial plugin implementation and decided to punt due to the growing scope at the time. Our concern at the time included the risk of a plugin dependency interfering directly with core dependencies. Also, we had an understandable concern with the level of support issues that would arise with plugins. As some time has now passed, I personally feel that the support burden has proved to be relatively low, or at least well below our estimations. Granted, it has only been a few months :)

The technical concern, certainly still exists, but I would still be in favor of supporting this, by allowing plugins to register a list of Django apps to be appended to INSTALLED_APPS.

@lampwins commented on GitHub (Sep 26, 2020): We mulled this over briefly in the initial plugin implementation and decided to punt due to the growing scope at the time. Our concern at the time included the risk of a plugin dependency interfering directly with core dependencies. Also, we had an understandable concern with the level of support issues that would arise with plugins. As some time has now passed, I personally feel that the support burden has proved to be relatively low, or at least well below our estimations. Granted, it has only been a few months :) The technical concern, certainly still exists, but I would still be in favor of supporting this, by allowing plugins to register a list of Django apps to be appended to `INSTALLED_APPS`.
adam commented 2025-12-29 18:32:54 +01:00
Author
Owner
Copy Link

@glennmatthews commented on GitHub (Nov 10, 2020):

Another example app that it would be helpful to be able to add is django-health-check

@glennmatthews commented on GitHub (Nov 10, 2020): Another example app that it would be helpful to be able to add is [django-health-check](https://django-health-check.readthedocs.io/en/latest/readme.html)
adam commented 2025-12-29 18:32:55 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jun 13, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jun 13, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 18:32:55 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 13, 2021):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Jul 13, 2021): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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 pending closure status: under review topic: plugins type: feature
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#4058
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?