Replies: 3 comments 1 reply
-
|
I don't have objections for rewriting What ideas do you have about recognizing the correct objects? Would As mentioned in #392 downloading the OpenAPI scheme is so slow (I haven't tried it for a long time though!) that it is not usable at all. My "unfortunate" situation currently is that I'm dealing with NetBox-integrated apps having components also in AWS Lambda, meaning that the short start time of the app is quite critical, for cold start situations. Some of my apps are also long-running, so I already have to manage them carefully in case of NetBox upgrades. Sometimes I make NetBox API version checks in the runtime to prepare for major upgrades, sometimes I just make sure I deploy new app versions at the same time I upgrade NetBox. And for some apps I have my own API with Amazon API Gateway so that I can mask out any changes in NetBox level 😁 So I have to be quite prepared for any upgrades and breaking changes, either in (Some of my comments in #531 are also applicable here) |
Beta Was this translation helpful? Give feedback.
-
FWIW the schema is now cached after the first generation, so only the first pull should be slow. We looked into rendering it statically but that presents issues e.g. with plugins. |
Beta Was this translation helpful? Give feedback.
-
|
For versioning, idea that I think would help is to match the major version of NetBox, so pyNetBox v3.3.x would work with NetBox v3.3 - the minor version would not be in-sync as those should be non-breaking changes and we would need some flexibility to release bugfix outside of NetBox version. So if you have NetBox 3.3.(something) you would know that pyNetBox v3.3.(anything) should work. |
Beta Was this translation helpful? Give feedback.
-
|
I already forgot that a made a blog post about I need to update that this week for 7.0.0/7.0.1. |
Beta Was this translation helpful? Give feedback.
-
Opening a discussion to get feedback for a potential rewrite of pynetbox. Currently the wrapper returns objects derived from Records and RecordSets and can return those type of objects instead of derived objects like Cables. In addition the object are pluralized so a single object would be "Cables". Some of this and the reasons for the current implementation can found in #392
Was thinking of the rewrite to map all the NetBox REST API objects directly to wrapper objects or Python lists - so if you call the /cables api you will get back a Python list of "Cable" objects. The would be no Record or RecordSet objects. I am thinking this is more what developers would expect from the API wrapper, but wanted to open this up for discussion from actual users of the API. Obviously these changes would require scripts using pynetbox to be re-written to some extent. Potentially would look at other things like typing support and have stronger data / schema validation.
Does this make sense or not? Are there any other major limitations or problems with the current implementation that you would like to see addressed in a rewrite (not bugs, just basic architectural issues or limitations)? Concerns?
Beta Was this translation helpful? Give feedback.
All reactions