[07:30:05] | * cpm has quit (Quit: Leaving) |
[10:23:42] | <abugida[m]> | No, I'm just using the Element app. |
[10:24:09] | <abugida[m]> | However I got the same result when I tried to open it in a browser |
[10:24:15] | <symbioquine[m]> | That's weird then, I'd expect it to work... |
[10:28:21] | <symbioquine[m]> | What version of Element is your browser running - a refresh might not get the latest version because it uses a heavily cached Web Worker implementation? (Click on the carrot `ˇ` near your name and click "All Settings", then "Help & About") |
[14:46:51] | <mstenta[m]> | symbioquine: saw your PRs - AWESOME! |
[14:47:09] | <mstenta[m]> | Will take a closer look next chance I get |
[14:47:51] | <mstenta[m]> | Quick thought (and bear with me if I'm missing something obvious): would it be possible to do it ALL in the farmOS `composer.json`? Rather than in `composer-project`? |
[14:48:26] | <mstenta[m]> | Feels like that might be cleaner - but I forget if there was a need for something in `composer-project`... sort of recall there was... |
[14:49:16] | <mstenta[m]> | Ideally we can try to keep the `composer-project` as simple as possible... since once someone sets one up we can no longer manage updates to it |
[14:49:35] | <mstenta[m]> | (not part of farmOS releases - it becomes "managed by the user" after initial creation) |
[14:50:28] | <symbioquine[m]> | I'm not sure... I tried https://github.com/symbioquine/farmOS/commit/ae8688a02a8d87589e76c497876... and didn't see my patch applied in https://github.com/symbioquine/farmOS/runs/1689830646?check_suite_focus=... |
[14:51:13] | <symbioquine[m]> | But I didn't dig very deeply into it, assuming that I was just missing something about how the composer.json files are used and that I needed to put the change in the farmOS-composer-project package's composer.json |
[14:52:05] | <mstenta[m]> | Hmm yea... I have this sneaking suspicion that something might be needed in the project... but I can't remember... would need to try it out |
[14:52:32] | <mstenta[m]> | The nice thing about stuffing all that stuff in farmOS `composer.json` is we can easily change/remove it in the future if need be |
[14:52:51] | <mstenta[m]> | The whole project vs distro `composer.json` still throws me off too |
[14:53:42] | <mstenta[m]> | I know *some* things don't work in the farmOS `composer.json`... like adding extra `repositories` |
[14:53:57] | <mstenta[m]> | Because Compoesr doesn't recurse into it for that specifically |
[14:54:09] | <mstenta[m]> | (We are dealing with that for the farmOS-map library right now) |
[14:54:22] | <mstenta[m]> | But oh man I'm excited for faster tests haha! |
[14:55:08] | <symbioquine[m]> | <mstenta[m] "I know *some* things don't work "> I'm probably missing something, but I'm not convinced that dev dependencies are used from the farmOs/--/composer.json file |
[14:55:51] | <mstenta[m]> | Ooh maybe that was it... |
[14:56:15] | <symbioquine[m]> | That said, if they are used I could come up with a couple other hypothesis' about why my patch wasn't applied... |
[14:56:33] | <mstenta[m]> | Well hmm... would it be worth just including that patch in non-dev? |
[14:56:40] | <mstenta[m]> | It's pretty dang simple! |
[14:57:55] | <mstenta[m]> | oh but ... ah sorry |
[14:58:04] | <mstenta[m]> | i really need to look before i speak haha :-) |
[14:58:06] | <symbioquine[m]> | Well, we also need the `brianium/paratest` dependency and I'm pretty sure that should be a dev-only dependency. |
[14:58:11] | <mstenta[m]> | i forgot all our testing stuff is in the project composer.json already |
[14:58:16] | <mstenta[m]> | yea |
[14:58:20] | <mstenta[m]> | nevermind |
[14:58:39] | <mstenta[m]> | hmm i wonder if we should consider making a separate "testing project composer.json" |
[14:58:56] | <mstenta[m]> | (doesn't need to block this, just thinking out loud) |
[14:59:45] | <mstenta[m]> | anywho... i'll test this out and merge soon! |
[15:00:10] | <symbioquine[m]> | ty 🙂 |
[15:00:16] | <mstenta[m]> | thank YOU! |
[15:01:06] | <symbioquine[m]> | I'm also considering sending a PR to make the tests run against MariaDB/SQLite in addition to Postgres - similar to what I'm doing with farmOS_wfs; https://github.com/symbioquine/farmOS_wfs/actions/runs/476748768 |
[15:01:39] | <mstenta[m]> | not a bad idea! |
[15:02:23] | <mstenta[m]> | possible to run those in parallel using the github aciton strategy you explored originally? |
[15:02:37] | <mstenta[m]> | (oh! that's what you're doing in farmOS_wfs!) |
[15:02:50] | <symbioquine[m]> | Yeah |
[15:02:58] | <mstenta[m]> | That's awesome |
[15:03:48] | <mstenta[m]> | PS: had first Farmier subscriber ask to install farmOS_wfs the other day :-) |
[15:04:19] | <symbioquine[m]> | Yay! Let me know if you have any questions or concerns in the code review... |
[15:05:03] | <mstenta[m]> | Cool! Unfortunately I might not have a chance for a bit - I told them might make sense to just start on the 2.x branch |
[15:05:43] | <mstenta[m]> | Pushing hard right now to get 2.x hosting set up so folks can start testing migrations |
[15:06:49] | <symbioquine[m]> | That makes sense. The 2.x version of farmOS_wfs will probably be way more useful to folks anyway since it exposes all assets, not just areas. |
[15:06:59] | <mstenta[m]> | Yea so exciting |