| [20:15:22] | <mstenta[m]> | <symbioquine[m]> "This is what I do......" <- Yes. For development it helps to have the whole codebase |
| [20:15:59] | <mstenta[m]> | mstenta[m]: But sites is the minimum for persistence in production |
| [08:53:41] | <symbioquine[m]> | <mstenta[m]> "But sites is the minimum for..." <- Yeah, it's a little wasteful, but can be helpful for reproducing a given state at the time of the backup. |
| [08:55:27] | <symbioquine[m]> | symbioquine[m]: I could probably stop doing that in favor of just saving the some sort of pointer to my repository revision or docker image now that I'm doing https://farmos.org/hosting/composer/ |
| [08:57:08] | <mstenta[m]> | symbioquine[m]: The other downside of mounting `/opt/drupal` is that you won't get the new version of farmOS simply by updating the Docker image. |
| [08:57:50] | <mstenta[m]> | mstenta[m]: Oh sorry this is about backups specifically... I misinterpreted it originally to be about volume mounts. So take comments with that in mind. |
| [08:59:31] | <symbioquine[m]> | mstenta[m]: Yeah, in production I'm mounting to `/opt/drupal/web/sites` but backing up `/opt/drupal/*` |
| [09:00:02] | <symbioquine[m]> | symbioquine[m]: (plus db) |
| [09:01:03] | <symbioquine[m]> | symbioquine[m]: It was necessary for reproducibility when I was doing everything via the docker-compose.yml file and versions of stuff weren't necessarily pinned fully. |
| [09:08:23] | <mstenta[m]> | symbioquine (and paul121) as a sidenote to that thread... I'm thinking more and more about making Composer one of the primary "recommended" installation methods |
| [09:09:35] | <symbioquine[m]> | Is it not already? |
| [09:10:17] | <symbioquine[m]> | Ah! Under here: https://farmos.org/hosting/install/#farmos-codebase |
| [09:10:21] | <mstenta[m]> | Maybe something like:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/QrWkjAPySCkdctjN...) |
| [09:10:43] | <symbioquine[m]> | Would be nice to have a little flowchart about which strategy to use 🤓 |
| [09:10:51] | <mstenta[m]> | Yea exactly |
| [09:11:35] | <mstenta[m]> | I think the first step of the flowchart is: do you just want default farmOS? Or also other modules? If the latter, we need to recommend Composer. |
| [09:11:44] | <symbioquine[m]> | Sounds right to me |
| [09:11:44] | <mstenta[m]> | After that, it's more about Docker vs non-Docker. |
| [09:12:20] | <mstenta[m]> | We could continue to say "it may be possible to install other modules without Composer, but it is not recommended" |
| [09:12:35] | <mstenta[m]> | Not using Composer is just asking for trouble, the longer time goes on... |
| [09:12:55] | <mstenta[m]> | (due to dependency version issues) |
| [09:14:04] | <symbioquine[m]> | Same lesson learned by all the popular language package managers - "you actually need a package version lock file" |
| [09:14:21] | <symbioquine[m]> | * the popular programming language package |
| [09:15:01] | <mstenta[m]> | Maaaaaaybe we can start providing a "farmOS Plus" Docker image/tarball that includes some contrib modules |
| [09:15:31] | <symbioquine[m]> | Hmmm, sounds like a can of worms 🪱 |
| [09:15:38] | <mstenta[m]> | For folks who really just want a click and go option (like all these new-fangled NAS app stores) |
| [09:15:40] | <mstenta[m]> | Yup. Agreed. |
| [09:16:16] | <mstenta[m]> | There is an audience for non-Docker-non-Composer installations I think |
| [09:16:55] | <mstenta[m]> | (Although automatically detecting version changes and taking a backup + running update.php might be necessary) |
| [09:17:08] | <mstenta[m]> | It's a question of how much hand-holding do we want to support long term |
| [09:17:19] | <symbioquine[m]> | Along similar lines there might be a way to have a "curated module repository" built-in without necessarily shipping/endorsing specific contrib modules |
| [09:19:15] | <mstenta[m]> | Nextcloud has barebones Docker images (like ours) but they also provide "All-in-One" options IIRC |
| [10:01:09] | <paul121[m]> | <mstenta[m]> "Not using Composer is just..." <- Yeah this needs to be highly recommended IMO |
| [10:02:27] | <paul121[m]> | It would be nice to have an example repo making a custom docker image based on a composer workflow. But agree it would be hard to maintain that as a suggested install method |
| [10:11:20] | <shplorf[m]> | <symbioquine[m]> "It was necessary for reproducibi..." <- Makes sense, thanks for the explanation! |
| [16:43:21] | * tool172[m] has quit (Quit: Client limit exceeded: 20000) |