| [20:10:02] | <paul121[m]> | > <@mstenta:matrix.org> Main differences from the previous approach:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/a08969105f...) |
| [14:05:28] | <paul121[m]> | soo I spent a couple hours last night re-writing farmOS.py 😅 |
| [14:06:15] | <paul121[m]> | but what's amazing is how easy it was... using this new httpx library! https://www.python-httpx.org/ |
| [14:07:13] | <paul121[m]> | > HTTPX is a fully featured HTTP client for Python 3, which provides sync and async APIs, and support for both HTTP/1.1 and HTTP/2. |
| [14:11:24] | <paul121[m]> | It really eliminates all of the http/client level logic we have in farmOS.py... it ends up looking like this:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/2ad0b63565...) |
| [14:11:54] | <paul121[m]> | *only* having helper methods that are wrappers around `client.request(...)` |
| [14:17:38] | <paul121[m]> | to be fair, this is much simpler because it doesn't handle authentication. httpx allows you to provide your own class to handle authentication flows: https://www.python-httpx.org/advanced/#customizing-authentication |
| [14:17:39] | <paul121[m]> | this is good for two reasons: |
| [14:17:39] | <paul121[m]> | 1) We should be able to use an existing/reusable OAuth2 auth class (like https://github.com/Colin-b/httpx_auth, although this doesn't seem quite perfect/mature) |
| [14:17:39] | <paul121[m]> | 2) You can make your own auth handler! |
| [14:22:03] | <paul121[m]> | symbioquine: I'm curious what you think about this. I believe httpx addresses many of the points you made awhile back... https://github.com/farmOS/farmOS.py/issues/31 |
| [14:22:03] | <paul121[m]> | hybrid async/sync methods, supporting different async backends, pluggable authentication, etc.. but most importantly at a lower level, where it really makes sense to do so!! |
| [14:22:44] | <paul121[m]> | my current code is here (all tests passing except for a weird subrequests bug!!) : https://github.com/farmOS/farmOS.py/compare/1.x...paul121:1.x-httpx?expa... |
| [14:25:41] | <paul121[m]> | Usage:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/cfe58ac886...) |
| [14:28:21] | <paul121[m]> | the biggest thing holding me back is that this httpx_auth library isn't quite perfect... it supports many of the OAuth2 classes but only uses the original `access_token`, it doesn't support refreshing with a `refresh_token`. It also doesn't support async authentication. But these are things we could implement ourselves, might be better than having another dependency. |
| [15:19:43] | <symbioquine[m]> | > <@paul121:matrix.org> symbioquine: I'm curious what you think about this. I believe httpx addresses many of the points you made awhile back... https://github.com/farmOS/farmOS.py/issues/31 |
| [15:19:44] | <symbioquine[m]> | > |
| [15:19:44] | <symbioquine[m]> | > hybrid async/sync methods, supporting different async backends, pluggable authentication, etc.. but most importantly at a lower level, where it really makes sense to do so!! |
| [15:19:44] | <symbioquine[m]> | Unless something's changed at the Python level, there isn't really a way to abstract out the dual async/sync support. You either end up doing code transformation/rewriting like I was doing or you end up duplicating the code in `FarmClient`/`AsyncFarmClient`. |
| [15:29:05] | <paul121[m]> | Ah yes.. that's the same situation. There is an `unasync` library that tries to help do this, copy _async code into a new _sync folder.. |
| [15:29:56] | <paul121[m]> | It seems like you do this or maintain both sets of code |
| [15:29:57] | <symbioquine[m]> | As I recall, that was a big part of my proposal was how to organize the code such that the API would make sense while cleanly supporting both. |
| [15:30:53] | <symbioquine[m]> | The part we couldn't reach a consensus on was how much farmOS.py should abstract the API. |
| [15:31:44] | <symbioquine[m]> | I still feel that it's pretty trivial to use the API directly via requests or a similar library so the value proposition of farmOS.py should be in providing an abstraction of some sort. |
| [15:32:29] | <symbioquine[m]> | * how much `farmOS.py, * farmOS.py` should |
| [15:32:43] | <symbioquine[m]> | * proposition of `farmOS.py, * farmOS.py` should |
| [15:33:32] | <paul121[m]> | In others words, farmOS.py not depend on any http client itself? |
| [15:34:00] | <symbioquine[m]> | Well maybe, but that's not what I meant by abstraction |
| [15:35:02] | <symbioquine[m]> | I meant abstracting the API details so you're interacting with a Python version of the farmOS data model, not the farmOS data model strained through a `JSON:API` sieve. |
| [15:36:03] | <symbioquine[m]> | (Though at the time I wrote that proposal it wasn't `JSON:API`) |
| [15:36:47] | <paul121[m]> | Ah yes |
| [15:37:00] | <paul121[m]> | We should chat more about this. There might be a couple layers |
| [16:06:20] | <mstenta[m]> | https://github.com/farmOS/farmOS/pull/544 |
| [16:06:46] | <mstenta[m]> | Finished the documentation this morning |
| [16:07:02] | <mstenta[m]> | Ready to merge if y'all approve! |
| [16:21:26] | <symbioquine[m]> | Left a couple minor comments |
| [16:35:09] | <mstenta[m]> | Thanks symbioquine! Replied... |
| [17:47:01] | <mstenta[m]> | symbioquine: what do you use for creating screen recording gifs? |
| [17:52:06] | <symbioquine[m]> | Peek |
| [17:52:30] | <symbioquine[m]> | https://github.com/phw/peek |