Composer vs Git Submodule vs Git Subtree

[addison74]

Parts of OpenMage are more or less active projects on GitHub (ZF1-Future, phpseclib/phpseclib, phpseclib/mcrypt_compat, pear/net_idna2, colinmollenhour/cache-backend-redit, collingmollenhour/magento-redis-session, magento-hackathon/honeyspam, fballiano/openmage-image-cleaner, ...). I would propose a discussion related to the periodic updating of these code parts.

There is Composer whose advantages from the perspective of the PHP programmer I will never deny, but we could analyze another alternative, the use of Git Submodule or Git Subtree.

I would be a supporter of Git Subtree for several reasons. Here are just a few: keeping OpenMage in the initial file structure, so anyone can download it as an archive/clone and use it immediately, without having to install Composer (not everyone has root access, not all system administrators are familiar with it, what happens is something goes wrong with dependencies?).

[Flyingmana]

Does the github download even include git submodules?
makes probably providing a composer package very complicated/incomplete?

[addison74]

I haven't used submodules with GitHub but I brought projects to local installations. For example, I am testing ZF1-Future and it is a submodule in one of my installation. I do its update manually, but it can be done by setting a cronjob to do it periodically.

Most likely if we establish what certain parts of OpenMage are submodules then anyone locally can make an update to one or more submodules then he can propose a PR with the file changes. Honestly speaking, I haven't read any articles on this topic (GitHub submodules implementation), but I'm sure others have done it before us.

[Flyingmana]

on a first google search it seems like various projects hit a roadblock making it available via the github download. Which means, it would also not be part of the package composer installs. So the directory structure would still break for composer users.

[addison74]

What concerns me is the fact that most of us want to detach certain parts of OpenMage which are separate projects and maintained in other repositories. Now we have 3 options to use OpenMage: download the archive, clone the repository or use Composer.

Once removed from the repository, in order for OpenMage to work, a mandatory step will be required to bring these removed parts of the code. Composer was proposed, which in my opinion does not completely solve the problem. In order to cover the other scenarios, an option would be Git Submodules, but as in the case of Composer, the opinions are divided, but favorable to Submodules. Those who complain consider that every contributor must update to see the code. Some of them support Git Subtrees, which in their opinion is a better solution because the update stage is no longer necessary.

[justinbeaty]

As @Flyingmana mentioned, submodules would break composer. So the libraries would have to be both a submodule and in composer.json which creates a problem if they're not kept in sync because bugs could be present in one method of installing but not another.

Here's a chart I made that should outline the possible methods we can use:

The two columns are using libraries as submodules vs putting them in composer.json. The four rows are the various ways one could obtain OpenMage.

So by going the submodule route, we break composer install and by going the composer route, we break git clone. In both cases we're breaking the download ZIP function, and so we must introduce the release builder script.

But in my opinion, composer.json is the only way to go. Maybe someone manages their non-composer install by forking OpenMage and applying their changes on top, and their method is going to break, but I would bet far more people use composer.

[fballiano]

Yep, it's not possible for a OM module to be a git submodule. Also, is it possible with submodules to "tie" to a specific branch/tag/version? IMHO that would be crucial.

The only "problem" with composer is that you have to "git clone; composer install" but I'd say it's something everybody is used to do nowadays (actually we're probably the only project not to do it yet ehheheh).

Another thing, who's cloning the repo really? I don't think that many end users do that. Old style end users (like me with some of my projects) download the tarball and extract it on the docroot of the project. I never cloned the repo until I wanted to contribute.

The release builder is ready, we just need to fix the details when we'll have the first external packages in the official composer.json, but it's gonna be easy.

[kiatng]

Another thing, who's cloning the repo really?

Me! Even for production, I like to see the history of who did what and when, to the code.

[sreichel]

Another thing, who's cloning the repo really?

Me! Even for production, I like to see the history of who did what and when, to the code.

Maybe missunderstood. Common practice ... ?

• do git clone once
• have an update/deploy script for git pull and composer install

No?

[kiatng]

* do `git clone` once

* have an update/deploy script for `git pull` and `composer install`

No?

I think I only run composer install 2-3 times in my career, I know next to nothing about it. The first time was trying to install Sylius, which turned out to be too complicated for me then, I gave up. But I think I can manage this sequence git pull and composer install. OM, since the beginning of M1, is a monolith, meaning, it is self-contained, run right out of the box. Even people like me, who was just a wanna-be web developer, knew nothing about HTML, CSS, LAMP, etc, could followed the guide, installed it and played. Is monolith dead?

[sreichel]

OM, since the beginning of M1, is a monolith, meaning, it is self-contained, run right out of the box

Think, we move away/forward. As said somewhere else, i'd make composer mandatory, BUT if we do so, we should provide instructions or workflows that everyone can easily adapt ...

Is monolith dead?

Y (imho)

[sreichel]

@addison74 thanks for bringing this up.

I was about asking a similiar question - just from another point of view.

My questions/suggestion was about to rely on composer (make it mandatory).

Would it be a BC break? No.

We dropped support for php5 and enforced users to update their env. Why not doing this for composer?

During past years i've either seen up-to-date servers (with plesk/cpanel/..., highly configurable, of course with composer) or completly outdated servers, still running on php5, w/o composer ...

For every, EVERY, project i had to move to OM, php7.x + composer was a/my requirement.

---

Release builder ...

@fballiano i highly appreciate this work, but will it work for different setups? My PR #2340 would require to built three releases (7.0, 7.1., 7.2+). It is certainly possible, but is it worth the effort?

[addison74]

@sreichel - The discussion was welcome so that we could all share an opinion or improve our knowledge. I appreciate that many opinions have been expressed, an evaluation can be made and a decision can even be take.

At the moment if we have a local OpenMage to update it we have several options available:

• downloading the archive and copy it to the directory
• bringing the repository up to date with the Git command
• bringing the repository up to date with Composer

If parts of OpenMage will be removed and they will be managed as composer dependencies, I think that the repository can no longer be updated with the Git command. For this reason, I suggested that there be another submodule/subtree alternative. Now for testing ZF1-Future I use Git Subtree (I update with squash so that there is 1 commit) and it is fine, but if there are more trees Composer is a winner. With a single command, all the dependencies are updated. It is true that I can make a script for Git as well, but if there are issues they will have to be solved separately and it will take more time. In a host sharing, Composer does not need to be installed but can be used in the command line if php can also be run.

When we remove those dependencies from OM we should inform on the repository page what happens with the Git commands (fetch/merge/pull) and the mandatory use of Composer. Maybe creating a tutorial in the home page explaining how it will work for those who until then cloned the repository and periodically updated it. If they don't use Composer then they won't have the whole package to run and obviously issues will occur. I even refer them to "How to install Composer" because really OM is monolithic and many have learned to run it just by downloading and unzipping the archive.