| [06:36:55] | * evered[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [06:36:56] | * paul121[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [06:36:58] | * jgaehring[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [06:37:02] | * mstenta[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [06:37:02] | * symbioquine[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [06:37:02] | * FarmerEd[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [06:37:03] | * wotnak[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [06:37:03] | * lordeddi[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [06:37:03] | * wildhavenfarm[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [06:37:03] | * r3c4ll[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [06:37:04] | * EricLarese[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [06:37:06] | * OctavioMartnDuar has quit (Quit: Bridge terminating on SIGTERM) |
| [06:37:07] | * YashGoel[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [06:37:08] | * piegeux[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [06:37:08] | * monkeyflowerfarm has quit (Quit: Bridge terminating on SIGTERM) |
| [06:37:10] | * pcambra[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [06:37:11] | * fosten[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [06:40:44] | * mstenta[m] has joined #farmos |
| [06:49:27] | * dazinism[m] has joined #farmos |
| [06:49:27] | * spitz234[m] has joined #farmos |
| [06:49:39] | * EricLarese[m] has joined #farmos |
| [06:49:39] | * piegeux[m] has joined #farmos |
| [06:49:39] | * lordeddi[m] has joined #farmos |
| [06:49:39] | * gbathree[m] has joined #farmos |
| [06:49:39] | * paul121[m] has joined #farmos |
| [06:49:39] | * evered[m] has joined #farmos |
| [06:49:39] | * wotnak[m] has joined #farmos |
| [06:49:39] | * symbioquine[m] has joined #farmos |
| [06:49:39] | * r3c4ll[m] has joined #farmos |
| [06:49:39] | * scrdcow[m] has joined #farmos |
| [06:49:40] | * OctavioMartnDuar has joined #farmos |
| [06:49:40] | * wildhavenfarm[m] has joined #farmos |
| [06:49:40] | * monkeyflowerfarm has joined #farmos |
| [06:49:40] | * FarmerEd[m] has joined #farmos |
| [06:49:40] | * pcambra[m] has joined #farmos |
| [06:49:41] | * jgaehring[m] has joined #farmos |
| [06:49:41] | * YashGoel[m] has joined #farmos |
| [06:49:41] | * fosten[m] has joined #farmos |
| [07:06:06] | <lordeddi[m]> | hi! created a small PR for farm.org |
| [07:06:19] | <lordeddi[m]> | s/org/OSorg monthly call page (riot is now element)/ |
| [07:06:37] | <lordeddi[m]> | https://github.com/farmOS/farmOS.org/pull/66 |
| [07:13:53] | * piegeux[m] has quit (Ping timeout: 246 seconds) |
| [07:13:53] | * lordeddi[m] has quit (Ping timeout: 246 seconds) |
| [07:13:53] | * gbathree[m] has quit (Ping timeout: 246 seconds) |
| [07:13:57] | * jgaehring[m] has quit (Ping timeout: 246 seconds) |
| [07:13:57] | * YashGoel[m] has quit (Ping timeout: 246 seconds) |
| [07:13:57] | * fosten[m] has quit (Ping timeout: 246 seconds) |
| [07:14:01] | * paul121[m] has quit (Ping timeout: 256 seconds) |
| [07:14:03] | * wotnak[m] has quit (Ping timeout: 248 seconds) |
| [07:14:08] | * symbioquine[m] has quit (Ping timeout: 260 seconds) |
| [07:14:08] | * r3c4ll[m] has quit (Ping timeout: 260 seconds) |
| [07:14:08] | * scrdcow[m] has quit (Ping timeout: 260 seconds) |
| [07:14:10] | * EricLarese[m] has quit (Ping timeout: 252 seconds) |
| [07:14:11] | * evered[m] has quit (Ping timeout: 252 seconds) |
| [07:14:11] | * mstenta[m] has quit (Ping timeout: 252 seconds) |
| [07:14:30] | * pcambra[m] has quit (Ping timeout: 265 seconds) |
| [07:14:36] | * OctavioMartnDuar has quit (Ping timeout: 264 seconds) |
| [07:14:36] | * wildhavenfarm[m] has quit (Ping timeout: 264 seconds) |
| [07:14:36] | * monkeyflowerfarm has quit (Ping timeout: 264 seconds) |
| [07:14:36] | * FarmerEd[m] has quit (Ping timeout: 264 seconds) |
| [07:14:36] | * dazinism[m] has quit (Ping timeout: 264 seconds) |
| [07:15:04] | * spitz234[m] has quit (Ping timeout: 260 seconds) |
| [07:32:25] | * paul121[m] has joined #farmos |
| [07:34:23] | * lordeddi[m] has joined #farmos |
| [07:34:25] | * piegeux[m] has joined #farmos |
| [07:34:28] | * gbathree[m] has joined #farmos |
| [07:35:50] | * symbioquine[m] has joined #farmos |
| [07:35:58] | * r3c4ll[m] has joined #farmos |
| [07:35:58] | * scrdcow[m] has joined #farmos |
| [07:37:18] | * jgaehring[m] has joined #farmos |
| [07:37:18] | * fosten[m] has joined #farmos |
| [07:37:28] | * YashGoel[m] has joined #farmos |
| [07:39:03] | * wotnak[m] has joined #farmos |
| [07:40:36] | * EricLarese[m] has joined #farmos |
| [07:40:42] | * evered[m] has joined #farmos |
| [07:41:04] | * mstenta[m] has joined #farmos |
| [07:41:52] | * pcambra[m] has joined #farmos |
| [07:42:23] | * wildhavenfarm[m] has joined #farmos |
| [07:42:24] | * OctavioMartnDuar has joined #farmos |
| [07:42:24] | * FarmerEd[m] has joined #farmos |
| [07:42:28] | * monkeyflowerfarm has joined #farmos |
| [07:42:41] | * dazinism[m] has joined #farmos |
| [08:15:08] | * spitz234[m] has joined #farmos |
| [11:00:04] | * YashGoel[m] has quit (Quit: You have been kicked for being idle) |
| [11:52:22] | <symbioquine[m]> | Dev call in about 8 minutes! |
| [12:01:15] | <symbioquine[m]> | https://meet.jit.si/farmos-dev |
| [13:16:45] | * botlfarm[m] has joined #farmos |
| [13:16:46] | <botlfarm[m]> | Hey, I have a problem that has been happening past few times I do an update, just have not had the time to ask questions in the past. When I do an update I change the version number in docker-compose.yml, shut down the image then restart it. When I run the update.php it shows I have missing modules. the missing modules are all ones I have installed by drush. For example the NRCS module I used composer require 'drupal/farm_nrcs:^2.1'. this |
| [13:16:46] | <botlfarm[m]> | is not a problem to reinstall these each time, but seems like I may be doing something wrong. |
| [13:17:37] | <paul121[m]> | symbioquine: you should add the asset link [docs](https://symbioquine.github.io/farmOS_asset_link/assetlink-plugin-api/ind...) to the [repo](https://github.com/symbioquine/farmOS_asset_link) ;-) |
| [13:18:38] | <paul121[m]> | (unless I'm just not seeing it... tried following the "github-pages" environment link but goes to a 404) |
| [13:23:24] | <paul121[m]> | <botlfarm[m]> "Hey, I have a problem that has..." <- Ah.. so the default farmOS docker image won't keep any additional modules you add with composer. This is because our (recommended) docker instructions only persist the `opt/drupal/web/sites` directory, not `opt/drupal/web/modules`: https://farmos.org/hosting/install/#persistence |
| [13:24:37] | <paul121[m]> | And that is for good reason - if you were to persist /opt/drupal/web/modules then you would not get any module updates that the new version of farmOS may depend on |
| [13:28:12] | <botlfarm[m]> | thanks paul121: So I used to install modules by downloading the tar.gz to the sites/all/modules directory and manually installing it. Is this the preferred method to keep modules between updates or is there a better way to direct it to that folder with composer? |
| [13:29:42] | <paul121[m]> | Right! I was just remembering you had been using the packaged release... welcome to docker :-) |
| [13:30:27] | <paul121[m]> | Yes, you could manually copy the farm_nrcs module source into the sites/all/modules directory. That might be a hybrid approach |
| [13:30:59] | <paul121[m]> | But if there is an update to farm_nrcs you would need to bring in the update yourself |
| [13:31:52] | <paul121[m]> | With a composer based workflow composer would managed all of the dependencies - but I don't think there is a good way of doing that with the default farmOS image |
| [13:33:11] | <paul121[m]> | I'm not sure we have an "official recommendation" on how to solve this... perhaps we should.. but there is no 1 right answer.. |
| [13:33:29] | <botlfarm[m]> | OK. I moved to using composer to keep the modules up to date. The old method of install worked fine, maybe I will switch back |
| [13:35:54] | <paul121[m]> | Here is where I have landed: |
| [13:35:54] | <paul121[m]> | - Started creating a custom docker image, based on core farmOS image, but includes custom dependencies: https://github.com/paul121/farmos-docker-site |
| [13:35:54] | <paul121[m]> | - Now I'm using platform.sh hosting (I'm not so interested in managing servers myself...) which is a pretty strict composer based workflow (no docker images to maintain): https://github.com/paul121/farmos-platform-template |
| [13:37:31] | <mstenta[m]> | Yea it would be good to provide some guidance on a recommended composer-based setup |
| [13:38:57] | <paul121[m]> | <botlfarm[m]> "OK. I moved to using composer to..." <- As long as you remember to add your composer dependencies back after pulling new docker images... I think that's a fine approach! Although if your docker container entirely shuts down you might lose things that are not persisted... hmm. |
| [13:40:25] | <mstenta[m]> | I wonder if it would be worthwhile to provide "enhanced" images too, which just include a bunch of contrib modules |
| [13:40:26] | <lordeddi[m]> | symbioquine: sorry my internet cut out. I didnt get to hear why you where coming back from the idea of precaching data in asset link |
| [13:40:37] | <mstenta[m]> | farmos/farmos-plus:2.x :-) |
| [13:41:47] | <paul121[m]> | could a docker image read in a custom composer.custom.json when it starts up? and add those dependencies? |
| [13:42:37] | <paul121[m]> | it wouldn't be perfect because you would still need to manage the `composer.custom.json` versions yourself... but would automate the "add modules back in after pulling new docker versions" |
| [13:42:57] | <paul121[m]> | in fact, Morgan may have a custom docker-compose entrypoint that does just that |
| [13:54:40] | <mstenta[m]> | composer install is run during the building of the image itself... so would that require basically running composer install again as part of the startup process? |
| [13:55:02] | <mstenta[m]> | to check for that composer.custom.json file? |
| [13:56:01] | <mstenta[m]> | my gut says that we shouldn't try to be too clever ... probably best to just provide guidance on how to maintain your own docker image, if you want to have a composer-based workflow and use docker |
| [13:56:52] | <mstenta[m]> | those two things could be separated too... eg: "how to have a composer-based farmOS setup" (outside of docker) + "how to have a composer-based farmOS setup inside Docker" (which explains how to build your own Docker image) |
| [13:59:38] | <symbioquine[m]> | mstenta[m]: I'm doing `composer require` in my "overridden" entrypoint, so yeah... |
| [14:10:34] | <paul121[m]> | <mstenta[m]> "farmos/farmos-plus:2.x :-)" <- this could be a good option! will always have the question of what to include... but perhaps this image could be built using our proposed strategies... with an easy repo to clone and further customize.. |
| [14:13:10] | <paul121[m]> | I wonder what format botlfarm would find easiest to follow for pursuing a composer based workflow.. I myself am not a good person to design it for :-) |
| [14:17:46] | <mstenta[m]> | Yea I'm happy to share how I do it for Farmier too, which has a set of contrib modules included. Basically it is a custom composer.json (originally created via composer create-project farmos/project) + a custom Dockerfile that is based on farmos/farmos which runs composer install during build |
| [14:19:36] | <mstenta[m]> | It's a tradeoff always... because with this approach you're essentially managing your own piece of software (which is a collection of farmOS + other packages) |
| [14:19:47] | <mstenta[m]> | Which isn't as "simple" of an ideas as just "run this docker container" |
| [14:19:53] | <mstenta[m]> | s/ideas/idea/ |
| [14:24:22] | <botlfarm[m]> | > I wonder what format botlfarm would find easiest to follow for pursuing a composer based workflow.. I myself am not a good person to design it for :-) |
| [14:24:23] | <botlfarm[m]> | I honestly don't really know what that means. :) From this discussion it seems there is a difference between docker based and composer based flows. Over my head for now, but constantly learning. |
| [14:25:38] | <mstenta[m]> | Well... there's "composer based setup"... and then there's the option to wrap that in a Docker image :-) |
| [14:26:10] | <mstenta[m]> | Right now we "ship" farmOS in two ways: a tarball (which can be dropped into an Apache webroot), and a Docker image |
| [14:26:31] | <mstenta[m]> | BOTH use composer install to build them |
| [14:26:55] | <mstenta[m]> | That's our way of providing something without users needing to learn composer |
| [14:27:50] | <mstenta[m]> | But you can use composer directly to build your own codebase! That's what I'm referring to as the "composer based setup". That alone will give you a codebase that can be dropped into an Apache webroot. |
| [14:28:01] | <mstenta[m]> | You could then take it a step further and put it inside a Docker image |
| [14:29:52] | <mstenta[m]> | The conversation above is sort of starting there but then also thinking about ways of making the composer based setup more approachable, but providing additional automated options... but I'm not sure we should go that route (at least not "officially" - but folks could certainly make their own repos and offer them to the community to provide variations of solutions) |
| [14:30:08] | <mstenta[m]> | s/but/by/ |
| [14:30:37] | <mstenta[m]> | I think the farmOS core docs should just cover: 1) tarball install, 2) Docker install, 3) how to use composer to build your own codebase |
| [14:30:43] | <mstenta[m]> | The docs already cover 1 and 2 |
| [15:57:14] | * keylum88[m] has joined #farmos |
| [15:58:16] | <keylum88[m]> | Hello, I just set up a trial account for farmos hosting |
| [15:59:12] | <keylum88[m]> | I have a local development environment running and I was wondering how I would be able to set it up so that the data from my local environment saves to the online one |
| [16:00:23] | <keylum88[m]> | I assume I would use farmOS-aggregator? |
| [16:01:34] | <mstenta[m]> | You could write a script that syncs data to the online one if you really wanted to |
| [16:01:55] | <mstenta[m]> | The aggregator isn't really the tool for that |
| [16:02:04] | <keylum88[m]> | ok |
| [16:02:16] | <keylum88[m]> | that sounds a lot more simple :) |
| [16:02:31] | <keylum88[m]> | the data from my local environment is in a postgreSQL db |
| [16:02:50] | <keylum88[m]> | which I am not familiar with. I have always used mySQL |
| [16:03:09] | <mstenta[m]> | If you write a general purpose script it could be useful to others! |
| [16:03:24] | <keylum88[m]> | so like in PHP? |
| [16:03:36] | <mstenta[m]> | I was imagining a script that interacts with the JSON API |
| [16:03:46] | <keylum88[m]> | ok |
| [16:03:53] | <mstenta[m]> | So could be any language |
| [16:04:10] | <mstenta[m]> | We have JS and Python libraries that might help |
| [16:05:11] | <mstenta[m]> | > that sounds a lot more simple :) |
| [16:05:11] | <mstenta[m]> | Still probably not very simple though :-) |
| [16:06:05] | <keylum88[m]> | yeah, I am realizing that lol |
| [16:06:14] | <mstenta[m]> | But it would be cool to have something like that for syncing two instances! |
| [16:06:28] | <mstenta[m]> | The real challenge is whether or not you want to allow writing in both |
| [16:06:41] | <mstenta[m]> | Or if the online one is just a copy/backup of the local one |
| [16:06:46] | <mstenta[m]> | Or vice versa |
| [16:07:11] | <mstenta[m]> | Maybe a bigger question to ask first is: why? What are you hoping to solve with two? |
| [16:07:26] | <keylum88[m]> | What I want is to use the online, but the local just be a backup if the internet goes down |
| [16:07:52] | <mstenta[m]> | Maybe you need something like asset link :-) |
| [16:08:19] | <mstenta[m]> | Offline capable client side JS app |
| [16:08:41] | <mstenta[m]> | symbioquine is working on that |
| [16:09:19] | <keylum88[m]> | that sounds awesome |
| [16:09:43] | <mstenta[m]> | Its a pretty big challenge to "sync" two instances I think (its sort of the same problem of syncing two databases generally... farmOS or not) |
| [16:09:48] | <symbioquine[m]> | https://farmos.discourse.group/t/asset-link-dev-log/1175 |
| [16:10:43] | <mstenta[m]> | Easy if one is the "canonical" and the other is just a copy... but two "canonicals" is going to be real hairy 😅 |
| [16:11:14] | <symbioquine[m]> | mstenta[m]: e.g. conflicting edits to the same asset/log |
| [16:11:28] | <keylum88[m]> | yeah, I understand |
| [16:16:18] | <keylum88[m]> | Thank you so much for the advice. I am gonna try some things out. |
| [16:16:19] | <keylum88[m]> | Very cool that you guys have this chat :) |
| [16:17:02] | <mstenta[m]> | Yea we have fun :-) |
| [16:17:09] | <mstenta[m]> | Welcome to the club! |
| [16:18:22] | <keylum88[m]> | thank you! ttyl :) |