In the current discussion about git submodules vs. composer there are several different underlying assumptions about the user's situation. I think it would help the discussion to clarify which use cases we are dealing with. Here is an attempt:
1) Shared hosting without shell. The user uploads code with (s)ftp, and can't install anything globally.
2) Shared hosting with non-root shell and git installed. The user can use git directly on the server, but can't install anything globally without root. They can manually download composer to their home directory.
3) Root on a (virtual) server. The user can install packages, and do any of the above.
The git submodules vs. composer discussion seems to focus on case 2). Case 1) could be addressed by providing a 'bundle' tar file with all dependencies that can be uploaded via (s)ftp. In case 2) composer or git can be used on the server to fetch dependencies separately.
When using git, it might be worth considering Parsoid's method of making the core repository a submodule of a 'core-deploy' repository which has all dependencies, rather than making the dependencies a submodule of core. This avoids issues with git complaining about dirty submodules in the common case of updating core often.
In case 3) the user has a full packaging system at their disposal, which means that it is theoretically possible to set up a fully-featured MediaWiki system with a few commands. So far we don't have any special support for this case (we expect users to follow the manual tarball setup), which made sense in the past as folks running their own server were fairly rare.
Many of our users are starting to take advantage of cheap virtual machines though, which are now widely available at a price point comparable to shared hosting. For this reason I think that we should put more effort into supporting case 3), for example by providing good Debian packaging which lets you do "apt-get install mediawiki-full" and get a MediaWiki install with caching, VisualEditor and so on. There are also other benefits here beyond the initial install, like automatic security updates with unattended-upgrades.
So far we don't have a good idea of how common the different use cases are, and how this distribution is changing. I think that we should try to get this information so that we can have a more informed debate.
Gabriel
On 2014-06-11, 11:47 AM, Gabriel Wicke wrote:
In the current discussion about git submodules vs. composer there are several different underlying assumptions about the user's situation. I think it would help the discussion to clarify which use cases we are dealing with. Here is an attempt:
- Shared hosting without shell. The user uploads code with (s)ftp, and
can't install anything globally. ... The git submodules vs. composer discussion seems to focus on case 2). Case
- could be addressed by providing a 'bundle' tar file with all dependencies
that can be uploaded via (s)ftp. In case 2) composer or git can be used on the server to fetch dependencies separately.
Shared hosting users using (s)ftp (1) inherently already use our tarball releases exclusively. No-one has suggested requiring extra steps for tarball users, any dependencies we use would be bundled with tarball releases.
The only thing being discussed is whether users that have already chosen to use git (and already have git) to clone core (which is technically supposed to be a dev tool even though people like to abuse it for production use) should have to run one extra command (either `composer install` or `git submodule update --init`) before it can be used.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
As Daniel hinted at, I'd like to add one more use case:
(4) prospective developers who want to do a small install for local testing and contribute patches.
This turns out to be very similar to use case (2), but it motivates the use of git (rather than a tarball) more strongly. Case (4) also prioritizes "low overhead" installs, ie can we get the developer setup and productive quickly enough that they don't lose interest. Approaches like using a sqlite3 database help case (4), even though it might not be reasonable to use sqlite for a "real" wiki (case 2) for performance reasons, regardless of the hosting situation. Gerrit-vs-Phabricator-vs-github and other tooling tradeoffs also matter for use case (4), as we want to minimize the total number of tools and packages the prospective developer needs to install/learn before they can test and submit their first patch. --scott
On 06/11/2014 12:29 PM, C. Scott Ananian wrote:
As Daniel hinted at, I'd like to add one more use case:
(4) prospective developers who want to do a small install for local testing and contribute patches.
Scott & I have started to summarize the use cases at
https://www.mediawiki.org/wiki/Distribution/Use_cases
Lets refine that page, so that we can use it as a reference while discussing solutions.
Gabriel
On 12/06/14 05:29, C. Scott Ananian wrote:
As Daniel hinted at, I'd like to add one more use case:
(4) prospective developers who want to do a small install for local testing and contribute patches.
For development, I like to have everything checked out from some kind of version control system, so that if I need to edit a third-party component, I can easily do that and have my changes tracked, so that a diff or commit can easily be generated.
Also, on my laptop, I have a privilege separation boundary between code editing (which is done as the main desktop user) and execution of bleeding-edge code. I think that's a very sensible boundary, since there is all sorts of private data available to the main desktop user, and code from git is often not reviewed. So I'm not going to run composer install hooks on my laptop as a user that can actually install code.
So I think for developers, either submodules or explicit git clones are the best solutions. But I don't think anyone is proposing a solution that would prevent explicit git clones.
-- Tim Starling
wikitech-l@lists.wikimedia.org