| [20:51:16] | * Noaht[m] has joined #farmos |
| [20:51:16] | <Noaht[m]> | The link in "More info on the farmOS 2.x api here" on this page (https://farmos.org/development/farmos-py/client_2x/) is broken. Can someone send the correct link? |
| [20:52:49] | <paul121[m]> | Oops! Should be this: https://farmos.org/development/api/ |
| [20:53:09] | <paul121[m]> | Thanks Noaht |
| [21:20:41] | <Noaht[m]> | What type of geometry is used for coordinate locations in the logs and how can I convert to that form from geojson?... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/cda8701e8e...) |
| [21:21:49] | <Noaht[m]> | * What type of geometry is used for coordinate locations in the logs and how can I convert to that form from geojson?... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/5a28f25e5f...) |
| [21:34:30] | <paul121[m]> | That is WKT |
| [21:35:54] | <Noaht[m]> | Awesome thanks. I found a library for it |
| [21:36:03] | <paul121[m]> | Looking in our docs to see if we mention this... We should add if we don't already |
| [21:36:15] | <paul121[m]> | Yeah, I think I've used one before |
| [21:36:46] | <Noaht[m]> | I've read through the docs and never saw anything. Could have missed it, but if it's not there I'd recommend it cause I spent a couple hours trying to figure it out haha |
| [21:42:10] | <paul121[m]> | Sorry about that!! I opened an issue to add that: https://github.com/farmOS/farmOS/issues/520 |
| [21:42:53] | <paul121[m]> | any feedback you have is valuable. fresh eyes see things that we will glance over |
| [21:44:46] | <Noaht[m]> | Is there any way to convert farmOS 1.x logs to farmOS 2.x logs? I wrote a log generator to generate harvest logs from a bunch of yield data I have, but I wrote it last Fall and it generates logs in the 1.x format. |
| [21:45:57] | <paul121[m]> | Ah. well if you only need to update your (python?) script that shouldn't be too hard |
| [21:46:13] | <paul121[m]> | Do you need to migrate existing logs from a 1.x server? |
| [21:49:25] | <Noaht[m]> | ACTION posted a file: (2KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/KQuOrIyOlcJ... > |
| [21:49:26] | <Noaht[m]> | ACTION posted a file: (20KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/wYWTqhTlURf... > |
| [21:49:27] | <Noaht[m]> | No I can regenerate them from my python script, that's not a problem. But the format seems to be quite different. Maybe I pulled them incorrectly from the API in the new farmOS. These are what I've been comparing between the two versions. |
| [21:50:41] | <paul121[m]> | Gotcha. Yes - the format looks quite different because we now use JSON:API |
| [21:51:02] | <paul121[m]> | If you didn't see already: https://farmos.org/development/api/changes/ |
| [21:51:33] | <Noaht[m]> | Yeah I saw that and read into it a bit, but I'm not super familiar with JSON:API. |
| [21:52:18] | <paul121[m]> | The main thing to know is that your log/asset object will all have "attributes" (simple data like name, status, notes), and "relationships" which are relationships to other JSON:API resources |
| [21:53:02] | <paul121[m]> | relationships for a log may be the assigned user and assets |
| [21:54:49] | <paul121[m]> | this may be the most complete farmOS.py example included in the docs.. https://farmos.org/development/farmos-py/client_2x/#assets |
| [21:57:08] | <Noaht[m]> | I see. Yeah, I read through the new api documentation. I was generating the logs by starting with an empty skeleton harvest_log object and then populating the data manually rather than using the farmOS API. |
| [21:57:47] | <Noaht[m]> | Hence the reason I was hoping for a simple way to just convert the ones I have. But I think it'd be better if I just used your farmOS.py module to do it |
| [21:58:50] | <paul121[m]> | Oh are you wanting to build the log objects but not send them to a server? |
| [22:00:49] | <Noaht[m]> | Well yes and no haha. I did this initially because I wasn't planning on using a farmOS instance I just wanted the objects, but we decided to use the server anyways later on |
| [22:01:22] | <paul121[m]> | I suppose one could build a python script to convert the 1.x logs into 2.x but no one has done that that I know of :-) |
| [22:02:37] | <Noaht[m]> | Its cool. We have a server up and running now so I can just scrap my original one and use your API instead. Seems straightforward enough to implement |
| [22:03:46] | <paul121[m]> | Cool. Something you might actually be interested in is farmOS.js for this |
| [22:04:35] | <paul121[m]> | It has a dedicated set of helpers for just creating farmOS entity objects: https://farmos.org/development/farmos-js/entities/ |
| [22:05:28] | <paul121[m]> | We've referred to it as the farmOS.js "model" API but I'm not sure I see that language in these docs.. |
| [22:05:38] | <paul121[m]> | I'm less familiar with that |
| [22:06:10] | <paul121[m]> | but in theory you could do the same in Python - it's using the JSON schemas provided by the server to build & validate entity objects |
| [22:07:57] | <paul121[m]> | You already have a server up and running, but farmOS.js has the schemata saved here: https://github.com/farmOS/farmOS.js/tree/main/core_schemata |
| [22:08:01] | <paul121[m]> | * has the *core schemata saved |
| [22:08:07] | <Noaht[m]> | How does that differ from the api? They're both still essentially just sending objects back and forth between the server right? |
| [22:09:27] | <paul121[m]> | So this "model" piece of farmOS.js will actually build a log/asset object that looks 95% like JSON:API, before ever interacting with the API! |
| [22:10:16] | <paul121[m]> | That is used in farmOS Field Kit when creating data offline |
| [22:10:42] | <Noaht[m]> | Ohhh I see. That may be a better option. I'll look into it. Thanks for the info! |
| [22:11:23] | <paul121[m]> | Sure thing. Sorry I can't explain that better, and I've got to run, but hope it helps |
| [22:11:47] | <paul121[m]> | jgaehring would be the one task if you have more questions on farmOS.js :-) |
| [22:12:19] | <paul121[m]> | there is also a community dev call tomorrow at 9AM PT if you want to join & bring any questions! |
| [22:51:00] | <Noaht[m]> | I'm trying to setup a local instance of farmOS 2.x with docker. After running the docker-compose file I'm unable to access it. Here is the output for the farmos-www-1 container:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/03481757c2...) |
| [22:51:16] | <Noaht[m]> | Any ideas? |
| [03:38:14] | * gvlx has joined #farmos |
| [05:54:01] | * gvlx has quit (Ping timeout: 248 seconds) |
| [07:18:44] | * gvlx has joined #farmos |
| [08:40:14] | * gvlx has quit (Ping timeout: 272 seconds) |
| [11:54:01] | <mstenta[m]> | Hi all the weekly farmOS dev call is starting in about 5 minutes - all are welcome :-) |
| [11:54:06] | <mstenta[m]> | https://meet.jit.si/farmos-dev |
| [11:54:25] | <mstenta[m]> | Hi Noaht just saw your message - if you want to hop into the dev call I'd be happy to take a look with you. |
| [11:54:50] | <mstenta[m]> | paul121 symbioquine if you're around I can show some work I'm doing on the Docker image build process |
| [11:55:06] | <symbioquine[m]> | Yeah, I'll be there :) |
| [12:08:43] | <paul121[m]> | Omw! |
| [13:18:23] | <paul121[m]> | fun call today :-) |
| [13:18:30] | <mstenta[m]> | yea! |
| [13:18:48] | <mstenta[m]> | symbioquine: i found the existing issue for the gh-pages demo https://github.com/farmOS/farmOS-map/issues/74 |
| [13:18:48] | <paul121[m]> | mstenta I think we are computing the centroid each time... here is the patch we sent to drupal/geofield: https://www.drupal.org/files/issues/2021-04-03/3207078-2.patch |
| [13:18:59] | <paul121[m]> | maybe we should change that? |
| [13:19:45] | <paul121[m]> | to use the lat/long that is stored in the DB? |
| [13:19:47] | <paul121[m]> | it was this issue: https://www.drupal.org/project/geofield/issues/3207078 |
| [13:20:09] | <mstenta[m]> | oh huh... |
| [13:20:43] | <mstenta[m]> | holy cow i have no memory of this hahaha |
| [13:21:54] | <mstenta[m]> | > maybe we should change that? |
| [13:21:54] | <mstenta[m]> | > to use the lat/long that is stored in the DB? |
| [13:21:54] | <mstenta[m]> | yea perhaps |
| [13:22:13] | <paul121[m]> | It does seem that the lat/lon saved in the db are truly the centroid: https://git.drupalcode.org/project/geofield/-/blob/8.x-1.x/src/Plugin/Fi... |
| [13:22:23] | <mstenta[m]> | right |
| [13:22:45] | <mstenta[m]> | yea it would make more sense to use that IMO |
| [13:23:05] | <paul121[m]> | that might speed things up a lot |
| [13:23:18] | <mstenta[m]> | yea i wonder |
| [13:23:44] | <mstenta[m]> | want to open a new issue in that module's queue? |
| [13:24:11] | <paul121[m]> | yeah. I'll do that today |
| [13:24:51] | <mstenta[m]> | heck i wonder if it will fix https://github.com/farmOS/farmOS-map/issues/157 ! |
| [13:25:24] | <mstenta[m]> | don't see how... but the fact that it's calculating that on-the-fly each time makes me curious |
| [13:25:38] | <mstenta[m]> | although... you said the geojson IS being cached, correct? so maybe not |
| [13:28:19] | <paul121[m]> | mstenta[m]: I need to double check this. I should inspect the response when it is correct, I think that will give us the answer |
| [13:28:44] | <paul121[m]> | IIRC correctly the full geometry geojson layers are cached... but maybe cluster is not |
| [13:28:44] | <mstenta[m]> | oh yea curious about that... wouldn't it be funny if this was the cause? |
| [13:28:50] | <mstenta[m]> | ahh |
| [13:29:47] | <mstenta[m]> | the fact that it is inconsistent is still puzzling |
| [13:29:53] | <paul121[m]> | BTW it looks like platform.sh has bcmath by default, but adding geos will be a little more work: https://docs.platform.sh/languages/php/extensions.html |
| [13:33:12] | <paul121[m]> | oh!! so the cluster geojson is always returning the "incorrect" value... which might very well be caused by not having geos |
| [13:33:29] | <paul121[m]> | thing is, sometimes the map will zoom to the clusters before the other vectors |
| [13:33:57] | <paul121[m]> | so the cluster is always in the wrong spot, it's just so far off that sometimes it isn't shown |
| [13:34:08] | <mstenta[m]> | ohhh |
| [13:34:20] | <mstenta[m]> | consistency! 🎉😄 |
| [13:34:57] | <paul121[m]> | so tldr; this is prob largely a bug on my hosting config, but maybe there are various improvements we can make at all levels of this haha |
| [13:35:38] | <mstenta[m]> | mm yea - well i wonder too about the inaccuracy without geos |
| [13:35:51] | <mstenta[m]> | but dunno if we should officially support that |
| [13:36:10] | <mstenta[m]> | (in v1 i tried to make sure that things would work as well as possible w/ and w/out geos, to support more folks) |
| [13:36:42] | <symbioquine[m]> | Does the reports page already warn if GEOS is missing? |
| [13:36:42] | <mstenta[m]> | that said... still waiting on a php8 compatible version of php-geos 😬 |
| [13:37:04] | <mstenta[m]> | (or wait... actually there might be a patch available iirc) |
| [13:39:12] | <paul121[m]> | I don't see anything about GEOS in admin/status/reports, maybe it should be mentioned |
| [13:40:39] | <paul121[m]> | I recently learned about `hook_requirements`, you can use the `runtime` phase to add to the status reports. Useful to see if an external API is up and running! https://github.com/paul121/farm_loocc/blob/cca8ccf76367b7ee868b506ed0ed2... |
| [13:41:14] | <mstenta[m]> | ah yea i thought there was a `hook_requirements` for `php-geos` but maybe not! |
| [13:41:34] | <paul121[m]> | * I recently learned about [`hook_requirements`](https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Extension...), you can use the `runtime` phase to add to the status reports. Useful to see if an external API is up and running! https://github.com/paul121/farm_loocc/blob/cca8ccf76367b7ee868b506ed0ed2... |
| [13:42:07] | <mstenta[m]> | ah! it's in the `geophp` module (which we no longer depend on) |
| [13:42:08] | <mstenta[m]> | https://git.drupalcode.org/project/geophp/-/blob/8.x-1.x/geophp.module#L79 |
| [13:42:20] | <mstenta[m]> | we could just replicate that logic in our own `hook_requirements()` |
| [13:42:38] | <symbioquine[m]> | ah, that explains it. |
| [13:42:42] | <symbioquine[m]> | I could have sworn I saw a warning about that in some testing a while back. |
| [13:43:11] | <mstenta[m]> | i could take a quick pass at adding that |
| [13:45:31] | <symbioquine[m]> | It seems kinda dangerous to support environments without GEOS if it's going to produce blatantly incorrect results. |
| [13:47:40] | <paul121[m]> | <mstenta[m]> "ah! it's in the `geophp` module..." <- huh, why is it that we no longer depend on this? |
| [13:48:01] | <paul121[m]> | I see `drupal\geofield` kinda handles it itself, is that why? |
| [13:48:08] | <mstenta[m]> | `geofield` used to - it doesn't anymore |
| [13:48:45] | <mstenta[m]> | with the move to composer - it became possible to just include `phayes/geophp` directly, rather than wrapping it in a drupal module |
| [13:48:56] | <mstenta[m]> | > It seems kinda dangerous to support environments without GEOS if it's going to produce blatantly incorrect results. |
| [13:48:56] | <mstenta[m]> | agreed |
| [13:49:35] | <mstenta[m]> | in https://farmos.org/hosting/install/ we currently state in the requirements: |
| [13:49:35] | <mstenta[m]> | > PHP BCMath extension and GEOS are recommended for more accurate geometric calculations. |
| [13:49:43] | <mstenta[m]> | i wonder if we should make that wording a bit stronger? :-) |
| [13:50:04] | <mstenta[m]> | ?*highly* recommended"? :-) |
| [13:50:14] | <mstenta[m]> | * "_highly_ recommended" :-) |
| [13:50:26] | <mstenta[m]> | PR inbound... |
| [13:52:49] | <symbioquine[m]> | Or "PHP BCMath extension and GEOS are required for accurate geometric calculations." |
| [13:53:23] | <symbioquine[m]> | or "PHP BCMath extension and GEOS are required for accurate geometric calculations. farmOS can be installed without these, but production usage without them is strongly discouraged." |
| [13:53:40] | <mstenta[m]> | I like that |
| [14:04:46] | <symbioquine[m]> | Do we have an issue for the edit control location problem? |
| [14:05:43] | <mstenta[m]> | no i don't think so |
| [14:05:50] | <symbioquine[m]> | k |
| [14:06:09] | <mstenta[m]> | oh wait we do |
| [14:06:10] | <mstenta[m]> | kinda |
| [14:06:10] | <mstenta[m]> | https://github.com/farmOS/farmOS-map/issues/135 |
| [14:06:20] | <mstenta[m]> | > There is an issue right now where the buttons overlap with the Snapping Grid control button. This is especially apparent when you select a feature with either the Move or Edit buttons, which then causes the Delete button to also appear. |
| [14:06:40] | <symbioquine[m]> | ah, yeah |
| [14:06:40] | <mstenta[m]> | that's where it was first described, although the proposed solution is intermingled |
| [14:07:25] | <mstenta[m]> | feel free to take that one over / rename / whatever |
| [14:07:56] | <symbioquine[m]> | Yeah, I think we should keep that open to track a more involved improvement/fix... |
| [14:08:17] | <symbioquine[m]> | I'll link them, but I'm not sure that should get closed in favor of this small CSS fix |
| [14:08:42] | <mstenta[m]> | ok |
| [14:13:25] | <symbioquine[m]> | https://github.com/farmOS/farmOS-map/pull/160 |
| [14:17:56] | <mstenta[m]> | https://github.com/farmOS/farmOS/pull/521 |
| [14:18:03] | <mstenta[m]> | wham bam! |
| [14:20:44] | <symbioquine[m]> | Maybe good to add a link to Paul's issue? |
| [14:21:01] | <symbioquine[m]> | or other past issues where folks have run into weird calculation problems? |
| [14:21:10] | <mstenta[m]> | just did 👍️ |
| [14:21:15] | <symbioquine[m]> | :) |
| [14:23:36] | <symbioquine[m]> | I think I'm going to hop offline for now... happy Thursday! |
| [14:24:00] | <mstenta[m]> | cool see ya symbioquine ! |
| [14:24:04] | <mstenta[m]> | thanks again for the help! |
| [14:25:38] | <mstenta[m]> | maybe we can plan on a farmOS-map release soon, before the next farmOS release |
| [14:26:49] | <symbioquine[m]> | Yeah, might need to check whether we've got the release process fully documented... I can't remember whether we're automatically pushing to NPM or not... |
| [14:27:29] | <symbioquine[m]> | Oh, I think we are :) |
| [14:28:01] | <mstenta[m]> | oh yea maybe something like this would be useful for farmOS-map too? https://farmos.discourse.group/t/2-x-release-procedure/1070 |
| [14:29:52] | <paul121[m]> | yes we need this delete button fix soon :-) |
| [14:33:32] | <mstenta[m]> | paul121: do you remember how to make farmOS-map releases? feel free to if you want! |
| [14:37:50] | <paul121[m]> | I think we just push a tag?? https://github.com/farmOS/farmOS-map/blob/2.x/.github/workflows/release.yml |
| [14:39:02] | <mstenta[m]> | i think we also need a commit |
| [14:39:20] | <mstenta[m]> | https://github.com/farmOS/farmOS-map/commit/6d25f8f9f862dccb376e78e93df8... |
| [14:40:20] | <mstenta[m]> | (i might add a comment to https://farmos.discourse.group/t/2-x-release-procedure/1070 with farmOS-map instructions...) |
| [14:43:40] | <paul121[m]> | Cool. I gtg for a bit, but yeah checking the last release commit should explain it then |
| [14:44:28] | <mstenta[m]> | I might be able to package one right now... |
| [14:44:32] | <mstenta[m]> | I'm documenting the process anyway |
| [14:45:45] | <mstenta[m]> | https://farmos.discourse.group/t/2-x-release-procedure/1070/4 |
| [14:46:02] | <mstenta[m]> | symbioquine: when you have a chance let me know if i missed anything there |
| [14:56:34] | <mstenta[m]> | https://github.com/farmOS/farmOS-map/releases/tag/v2.0.4 |
| [14:58:58] | <mstenta[m]> | https://github.com/mstenta/farmOS/commit/9bbd61cdb78406eda445754646d7929... |
| [15:01:38] | <mstenta[m]> | paul121: I'm curious about updating Gin and Simple OAuth before tagging the next farmOS release |
| [15:02:05] | <mstenta[m]> | I'll check out the MR you created for Gin. Do you recall where we left off with Simple OAuth? |
| [15:02:29] | <mstenta[m]> | I believe I had tested it out a bit in a branch ahead of PHP 8 stuff... need to refresh. Just flagging it now so you're aware I'm thinking about it. :-) |
| [15:02:33] | <mstenta[m]> | Gotta run now too... ttyl |
| [15:48:35] | <mstenta[m]> | FYI symbioquine paul121 my github actions PR is ready for review if you want to take a look: https://github.com/farmOS/farmOS/pull/522 |
| [17:12:42] | <paul121[m]> | <mstenta[m]> "I'll check out the MR you..." <- Looking at this now. So 5.x has EOL July 31, 2022 (see their project page) - that is our deadline :-) |
| [17:14:25] | <paul121[m]> | Here is the change record for 5.2.0: https://www.drupal.org/node/3255523 |
| [17:14:36] | <paul121[m]> | * now. So *5., * 5.0.x has |
| [17:21:53] | <paul121[m]> | We are already patching the first issue identified in the change record so we can remove that from our composer.json (as well our patch for updating something to be protected in their tests` |
| [17:23:38] | <paul121[m]> | The second issue mentioned in that change record might have some implications for the farmOS-aggregator - I know it interacts with the returned OAuth scope, so we may need to make some simple changes there. We may need to support both `scope` and `scopes` in the meantime. https://www.drupal.org/project/simple_oauth/issues/3247846 |
| [17:24:33] | <paul121[m]> | Other than that, we'll need to do some testing to make sure the first two patches we include for simple_oauth still apply & work as expected. Fortunately, we should have automated tests that cover all of those concerns |
| [17:25:54] | <paul121[m]> | (we should link to this simple OAuth change record in our changelog whenever we upgrade to this version) |
| [17:26:45] | <paul121[m]> | for those reasons I think we should hold off on 5.2.0 for a later release of farmOS |
| [19:35:34] | <Noaht[m]> | <mstenta[m]> "Hi Noaht just saw your message -..." <- Hi mstenta . Sorry, I had a meeting at the same time this morning and couldnt make it to the call. Are the dev meetings weekly? |
| [19:53:40] | <mstenta[m]> | Noaht: yep! Thursdays at 12 pm noon Eastern time @ https://meet.jit.si/farmos-dev |
| [19:55:24] | <mstenta[m]> | <paul121[m]> "Other than that, we'll need to..." <- paul121: just remembering this branch I started https://github.com/farmOS/farmOS/compare/2.x...mstenta:2.x-simple_oauth |