I’m hoping to gather some additional data about the use-cases and potential use-cases for farmOS Python APIs.
farmOS.py seems to have existed for almost a year now.
What are you using farmOS.py for today?
What do you imagine using farmOS.py or similar libraries for in the future?
More generally, what characteristics are most important to you in a farmOS Python library?
Abstraction;
High abstraction - “Provide a more ‘Pythonic API’ which favors a common abstraction which can work against past/current/future versions of farmOS over direct data parity.”
Low abstraction - “Provide a Python API provides some conveniences, but otherwise favors parity with the data directly surfaced the data from the rest API over abstraction or following Python conventions.”
Features;
Favor completeness - “I just want to have this one dependency, put everything in the main API.”
Favor minimalism - “Just support the core stuff, I can build on top of that or take dependencies that do.”
Dependencies;
More concrete dependencies - “The API should declare all the things it might depend on and everything should work without needing me to declare extra dependencies - at the risk that I might need to resolve dependency conflicts between the API’s dependencies and my other dependencies.”
Fewer concrete dependencies - “The API should only declare the bare minimum dependencies, if I use optional features, I’ll bring in the dependencies to support those as long as they are documented.”
Python version agnosticism;
“The API should work with everything >= Python 2.4.”
“The API should only require that I’m using Python 3 or so.”
“Give me the best stuff, even if it means the API only really works with >= Python 3.8.”
Synchronicity;
“The API just needs to support synchronous use-cases.”
“I have both synchronous and asynchronous use-cases for the API.”
“I’ll probably only use asynchronous part of an API.”
Configuration;
“Give me an opinionated configuration strategy for the API, I don’t want to evaluate/choose my own.”
“I already have a configuration framework in the code I use or want to use the API with, just make sure it works with configuration framework X.”
“I don’t care about config, just make sure I can use the Python part of the API without interacting with the ‘config’ part.”
The main motivation for these questions is some discussion we’ve been having in farmOS.py issue #31, but don’t feel obligated to read/follow that issue to chime in here!
Great list @Symbioquine! Another priority I would add is: library maintainability.
Specifically: how can we minimize the need for “ongoing maintenance” of the codebase (security updates, Python updates, etc) so that it is as resilient as possible to the inevitable ebbs and flows of open source maintainer availability. We’ve been able to bring the Python and JS libraries to where there are with some grant funding thusfar, but nothing lasts forever. The worst case scenario is something breaks in the future and no one is available to fix it. Minimizing dependencies helps in this regard, in my experience. And of course it’s unavoidable to some extent. But it’s always something I try to think about when writing code: “if I get hit by a bus, will this be able to live on it’s own long enough for someone else to take over?”
There’s a few general use cases of farmOS that I think about: (there very well may be others!!)
Being used to facilitate communication with a farmOS server for the backend of an application that displays, modifies or generates farmOS records.
Being used for scripting purposes as it makes the process of bulk importing/exporting farm data much easier (when working with custom CSV files, exporting data for researcher analysis, etc)
Potentially being used to upload sensor data when it is already collected in a python environment (on a raspberrypi or similar - currently uploading sensor data doesn’t require authentication with farmOS - so this might be better provided by a separate library, and it would really just be a convenience wrapper around a standardized http request. But, imo, it’s worth considering including here because it would be very minimal)
Characteristics based on these use cases:
Abstraction: I think all would most-benefit from higher abstraction, as long as that abstraction provides full capability to retrieve, create and manipulate farmOS records.
Features: #1 and #2 would tend to favor completeness. #3 might favor minimalism in low-memory/processing IOT environments (a reason for sensor support to be a separate library)
Dependencies: #1 may favor the bare minimum dependencies - but #2 might be used in more of a standalone way, where dependency conflicts are less likely
Python version: Don’t worry about Python 2.4, support Python 3, with greater (async?) features included with Python >= 3.8
Synchronicity: Async likely only needed (some of the time) in #1 - maybe this an external dependency, that would require higher Python versions?
Configuration: I think #1 and #2 should be able to adapt to any configuration strategy that happens via the API. #2 and #3 may also benefit from optional configuration that is saved via a config file or environment variables.
In the future I think farmOS.py will be used more in the “backend” of 3rd party applications. I’d also love to see it being used more and more for “scripting” - I’d love to document that more and help create tools that help import from custom spreadsheets. This might be something that farmers won’t use, but perhaps advanced users and farmOS “service providers”
Something i have slowly been working on and decided to develop more was a set of scripts that allowed me to do the things I wanted with FarmOS outside of the web.
I have been playing around with a data model setup that removes the FarmOS.py logistics and allows accessing assets/terms/logs as python objects. I know there are libs that could maybe do this better than I did. But then I don’t need to worry about dictionaries or parents and it will access those things as objects.
Still playing around, just finalizing creating a planting from the terminal.
That’s awesome @applecreekacres! So cool to see things like this develop! @paul121 and I have talked about similar ideas in farmOS.py itself eventually. Perhaps the repos can be on convergent paths in the future. Keep up the good work/exploration/experimentation!
Thanks @mstenta. I know the data model is low priority given the other changes like v2 so I haven’t tried merging it back yet (although I should try, if I could just get it stabilized and be happy with it )
)