standalone: agree distribution format(s)
Options:
OPTION 1 Encourage composer-template
OPTION 2 Encourage tar-ball (with current structure)
OPTION 3 Encourage tar-ball (with composer-like structure)
(And is it one of those options -- or two of those options)
Moved from chat to save an unwieldy thread therein.
i guess in theory # 1+# 3 sounds better than # 1+ # 2. but
- even drupal.org appears to be following a structure like # 1+# 2
- the workflow of "download+extract full tarball for composer-project" is a little weird for upgrades. (you need to delete+reset some folders -- but not other folders)
- i'm not entirely sure how to reconcile # 3 with the regular RC workflow. i'm sure it can be sorted; but it's more of a conversation
@demerit (sorry, don't know your handle here)
tarball tarball tarball
...
For initial installation, having a tarball that a user can just download and install is preferable because it is easier and lowers the barrier to entry. But is this going to make upgrades more tricky for them? What could we do to make upgrades easier in this scenario?
composer rules out hosting where you dont have shell access. Personally I'm cool with that, because you kinda need shell access to do things properly. Ftp for fun, shell for serious. (What a t shirt slogan!).
I dont like messy things like unpack this tarball, replace directories a, b, c swap out file d.
But I also don't love composer esp when it requires scripts to run. I tend to have my php as not owned by www-data, so the scripts won't run as www-data. Also in staging, where the httpd is in a container, I like to be able to manage the codebase from outside the container, but this will probably use a different php version. I'm happy to change my ways, though
Other projects I work with:
Nextcloud: provides a fairly solid upgrade script, even a web ui for upgrades, though they encourage CLI invocation to avoid timeouts. Files owned by www-data so the code writes the code. The CLI call to upgrade handles everything: checks, downloads, checksum checks, backups, moving files, running db migrations. It's solid and reliable, and there's a 'repair' command, in case something goes wrong (eg you tried your luck on the web ui method...)
Roundcube mail: provides an upgrade script as part of the new release. So you download tar, extract to tmp/ run a script from there like install-to.php /path/to/installation/dir/
I sometimes deploy by git too. I guess I could composer offline, commit, push, pull. I sometimes find composer flaky. There's one package that won't download or such. And it's slow (a zillion http requests) and can't be run offline.
But it let's you add bits to your site, e.g. if you have civi as part of a bigger project. Which is nice.
Tarballs are nice. Can be signed. Single download. Works offline.
Barrier to entry: hmmm. Idk tbh. You need CLI access at mo, and as long as there's a reliable few commands to run that can be copy pasted it makes no difference?
I'd quite like to be able to upgrade by git pull! Is that any more realistic in standalone? Probably red herring
🐡 Let's not do this though... curl https://civicrn.org/gimmestandalone | sudo bash
Please don't do anything that rules out hosting without shell access. That would discourage people from getting started with Civi, as I did and I've helped around 15 charities to get Civi - all hosted without shell access. I'm sure there are many in amongst the 4,000 D7 sites that don't have shell access.
2 on the list is similar to what I do with upgrades with D7 - after backing up, delete the CiviCRM code folder and unpack the tarballs into it. That's so easy, and adding some more to that would be no problem