Discussion: recommended way of installing Elgg 2.0 (composer or not)?

[iionly]

I've already posted my concerns about making installation via composer the recommended way of installing Elgg 2.0 at #8431. It has been suggested to discuss this topic in a separate issue.

As said before, I don't think that the installation via composer is suitable especially for inexperienced people. And especially these people will be additionally confused if the recommended installation is by composer. It seems to me that composer might be nice to use for developers and experienced users but I don't think it's that easy to use and failsafe as you might think (please try at least to see it from the perspective of a dummy user).

Addtionally: if you don't have command line access on the server or if the server is within an intranet without Internet access you won't be able to install via composer. If the composer installation is the recommended way but you can't use it it only results in more confusion.

If installation via composer is to be kept as recommended installation the install instructions should be at least more detailed (what is composer in the first place? how to install composer itself? what could go wrong and what to do then?).

But I would suggest to not make the composer installation approach the recommended way of installing Elgg. At least not yet for Elgg 2.0. I expect most people will download Elgg from the community site and taking these people (especially newbies) from there and guiding them through the more likely way of installation seems less troublesome. The composer installation can still be described as the alternative way of installing Elgg. And all the possible advantages of installing Elgg this way could be listed, too, in addition to a detailed description of how to proceed to allow a user to make a decision on which way suits him better.

[mrclay]

I also think it best to stick to the traditional installation and list the composer method as experimental for developers. We don't yet have a workflow for installing a particular version or upgrading and that seems a deal-breaker to me. Once those are worked out and docs are better we can change it.

[mrclay]

cc @ewinslow

[ewinslow]

I have changed the language to recommend either/both of the approaches depending on the audience.

My intent is that managed-with-composer is a first-class use-case for 2.0. I think it needs to not be experimental by the time 2.0.0 final ships. Therefore I am writing the docs as if it is not experimental now so we have less to change later.

I'm also confident shipping zip packages which are essentially elgg/starter-project composer-installed and zipped up will be better than zipping Elgg directly due to the fact that you can make local changes in the root directory and this will reduce the temptation to modify core.

[ewinslow]

shoot, we could even ship composer.phar in the zipped distro so that you can start with the elgg zip and then seamlessly transfer to composer when you want to upgrade.

[jdalsem]

"Regular" users will probably use the zip installation. But for bigger companies, or better automated companies, a composer install is way easier. It ensures identical installations over multiple servers and composer is supported in various CMDB tools. So both are good. I would not like to see it mentioned as experimental though, as that could imply that if it is broken, Elgg won't fix it...

[ewinslow]

What do we need to do to resolve this ticket? Take a vote or something?

[jdalsem]

I am currently fine with the current state. Both methods are mentioned (http://learn.elgg.org/en/master/intro/install.html#upload-elgg). Both are equally good. It is not that one is "bigger" then the other. I do not think (with the current amount of text) it makes a difference which one is mentioned first. I vote to keep it this way.

[mrclay]

IMO not being able to install a particular version is a blocking issue. We don't want end users using the master branch.

[ewinslow]

The thought is that elgg/starter-project:dev-master will always install the latest stable version. Right now it installs elgg master because there is no stable version of elgg that is composer installable.

[ewinslow]

I don't think we want people installing the master branch by default, but I don't think we need to allow picking a particular version either, at least not from the composer create-project command. If they want to edit the cloned project to specify the exact version, that can be done easily enough with composer require elgg/elgg:{version} && composer update

[ewinslow]

My recommendation would be to update the elgg/starter-project method to use elgg/elgg:^2.0 as soon as that stable version is available, and to use prefer-stable by default.

[ewinslow]

I've updated elgg/starter-project to point to 2.0.0-alpha.1 or higher and prefer stable versions. Anything else we need to do here?

[ewinslow]

Closing after 2 days of no objections. Please reopen if you feel it needs more attention.