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

Reusable/packaged netbox constants #1799

New Issue
Closed
opened 2025-12-29 17:19:13 +01:00 by adam · 5 comments
adam commented 2025-12-29 17:19:13 +01:00
Owner
Copy Link

Originally created by @dsanader on GitHub (Jun 19, 2018).

Hello,

I was wondering if you would consider moving netbox' constants.py into a separate dependency required by both netbox and pynetbox or maybe making an API endpoint for them.

Handling them is not much of an hassle, but It might feel more comforting to have them right away when using pynetbox.

Originally created by @dsanader on GitHub (Jun 19, 2018). Hello, I was wondering if you would consider moving netbox' `constants.py` into a separate dependency required by both `netbox` and `pynetbox` or maybe making an API endpoint for them. Handling them is not much of an hassle, but It might feel more comforting to have them right away when using `pynetbox`.
adam closed this issue 2025-12-29 17:19:13 +01:00
adam commented 2025-12-29 17:19:13 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 19, 2018):

Thank you for your interest in NetBox. It looks like your feature request is missing some information. Per the contributing guidelines, please ensure that you have provided all of the following:

  • A detailed description of the proposed functionality
  • A use case for the feature; who would use it and what value it would add to NetBox
  • A rough description of changes necessary to the database schema (if applicable)
  • Any third-party libraries or other resources which would be involved

Please update the issue so that it meets all of these requirements. If no response is received within a week, this issue will be closed. Thanks!

@jeremystretch commented on GitHub (Jun 19, 2018): Thank you for your interest in NetBox. It looks like your feature request is missing some information. Per the [contributing guidelines](https://github.com/digitalocean/netbox/blob/develop/CONTRIBUTING.md), please ensure that you have provided all of the following: * A detailed description of the proposed functionality * A use case for the feature; who would use it and what value it would add to NetBox * A rough description of changes necessary to the database schema (if applicable) * Any third-party libraries or other resources which would be involved Please update the issue so that it meets all of these requirements. If no response is received within a week, this issue will be closed. Thanks!
adam commented 2025-12-29 17:19:14 +01:00
Author
Owner
Copy Link

@dsanader commented on GitHub (Jun 19, 2018):

In pynetbox, I'd like to do the following without maintaining the constants by myself or using the hardcoded values :

nb.dcim.interfaces.create(device="somedevice", name="eth0", form_factor=IFACE_FF_1GE_FIXED)

I guess It would ease the use of pynetbox a bit and prevent some possible regressions in case of modifications on the constants part.

Adding special endpoints in the netbox API to expose the constants might be the way to go, since it would not be language dependent.

GET /api/dcim/constants/

{
    "dcim:constants": [
        {
            "IFACE_FF_100ME_FIXED": 800,
        },
        {
            "IFACE_FF_1GE_FIXED": 1000,
        },
        ...
    ]
}

That would require some work in the client libraries to cache this constants and make them reusable.

@dsanader commented on GitHub (Jun 19, 2018): In `pynetbox`, I'd like to do the following without maintaining the constants by myself or using the hardcoded values : ```python nb.dcim.interfaces.create(device="somedevice", name="eth0", form_factor=IFACE_FF_1GE_FIXED) ``` I guess It would ease the use of `pynetbox` a bit and prevent some possible regressions in case of modifications on the constants part. Adding special endpoints in the `netbox` API to expose the constants might be the way to go, since it would not be language dependent. ```GET /api/dcim/constants/``` ```json { "dcim:constants": [ { "IFACE_FF_100ME_FIXED": 800, }, { "IFACE_FF_1GE_FIXED": 1000, }, ... ] } ``` That would require some work in the client libraries to cache this constants and make them reusable.
adam commented 2025-12-29 17:19:14 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 29, 2018):

Adding special endpoints in the netbox API to expose the constants might be the way to go, since it would not be language dependent.

The interface form factors are available at /api/dcim/_choices/:

{
    "interface:form_factor": [
        {
            "value": 0,
            "label": "Virtual"
        },
        {
            "value": 200,
            "label": "Link Aggregation Group (LAG)"
        },
        {
            "value": 800,
            "label": "100BASE-TX (10/100ME)"
        },
        {
            "value": 1000,
            "label": "1000BASE-T (1GE)"
        },
        ...
}

Do you need the name of the constant itself exposed as well?

@jeremystretch commented on GitHub (Jun 29, 2018): > Adding special endpoints in the netbox API to expose the constants might be the way to go, since it would not be language dependent. The interface form factors are available at `/api/dcim/_choices/`: ``` { "interface:form_factor": [ { "value": 0, "label": "Virtual" }, { "value": 200, "label": "Link Aggregation Group (LAG)" }, { "value": 800, "label": "100BASE-TX (10/100ME)" }, { "value": 1000, "label": "1000BASE-T (1GE)" }, ... } ``` Do you need the name of the constant itself exposed as well?
adam commented 2025-12-29 17:19:14 +01:00
Author
Owner
Copy Link

@dsanader commented on GitHub (Jun 29, 2018):

Wonder how I missed that. :)

Labels should be enough for now. In the long run constants might be cleaner though (If you ever wish to localize the app maybe, or to enable some readable filtering /api/dcim/_choices/interface:form_factor/?label=100BASE-TX%20%2810/100ME%29).

Do wish me open an issue on the pynetbox project to discuss the retrieval part in it ? Even if writing a custom function isn't hard, a reusable builtin method would be nicer.

@dsanader commented on GitHub (Jun 29, 2018): Wonder how I missed that. :) Labels should be enough for now. In the long run constants might be cleaner though (If you ever wish to localize the app maybe, or to enable some readable filtering `/api/dcim/_choices/interface:form_factor/?label=100BASE-TX%20%2810/100ME%29`). Do wish me open an issue on the pynetbox project to discuss the retrieval part in it ? Even if writing a custom function isn't hard, a reusable builtin method would be nicer.
adam commented 2025-12-29 17:19:14 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 2, 2018):

@dsanader Feel free to open an FR against pynetbox for it. I haven't kept up much with pynetbox lately.

@jeremystretch commented on GitHub (Jul 2, 2018): @dsanader Feel free to open an FR against pynetbox for it. I haven't kept up much with pynetbox lately.
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
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#1799
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?