Maintaining Vanilla Distributions with Composer

Unknown
Unknown
in Dev & Ops

I've been thinking of some time about using composer to manage Vanilla distributions. I thought it would be really cool to define all of the add-ons you want available in a composer.json and composer manage all installation and updates for you.

How does it work?

I made use of custom composer installers for special vanilla package types. The installers plus some basic documentation is located on the repository here:

https://github.com/vanilla/composer-installers

The installers themselves are actually very easy and basically only do two things:

  1. Override the default composer installation path from vendor to a path I choose.
  2. Symlink everything from the custom folders into vanilla in a similar way to what we do now.

Scenarios

There are a few possible scenarios where this can be used:

Open Source

Open source could use this method to finally have an application updater. I doubt we'll ever really have a Wordpress style auto updater in Vanilla and given today's security climate I think there are strong reasons not to give such an ability to the web interface.

With a composer updater you get pretty close to an auto-updater. All you'd have to do is ssh into your server and run composer update and your server is updated. We could also support the use of composer require to add new add-ons to a site.

In order to support this scenario we'd have to do a bit of tinkering in order to allow the source code to be updated without deleting necessary files.

  1. We'd need to ensure that source code and files are not mixed. This means moving config-default.php and constants.php our of the conf directory. Perhaps they could just go into the root folder of vanilla.
  2. The cache, conf, and uploads folders would have to be removed from the project so as not to be overwritten during updates. They could instead be created by the composer install.
  3. Vanilla would be run with different symlinks. I'm not sure if this would pose a problem on some servers so we'd have to do some research.

Development

It may be a help developers to be able to grab and symlink a bunch of plugins with a single command rather than having to do it themselves. There are a few interesting things that could be done here:

  1. With the correct composer options you should be able to do installation via git cloning.
  2. You could leave the vanilla/vanilla package out of your composer.json and handle that repo yourself.
  3. We could provide an directory for other repos that aren't maintained through composer, but symlinked nonetheless.

Docker Containers

I'm not a docker expert, but I think composer distribution would work really well with docker containers. With a single composer.json and composer.lock file you can describe an entire Vanilla distribution that can be committed to source code.

Infrastructure Deploys

Our difficulties with deploying our ever increasing number of clusters was my original impetus for coming up with this composer strategy. I understand ops has a different way of doing this, but perhaps they can look at this for inspiration.

What's Next?

This is all pretty early and I'm not sure if I'll explore this further anytime soon. I mainly thought I'd gauge interest.

Comments

  • Vanilla Forums
    Vanilla Forums
    edited October 2018

    This feels like (part of) a path to make the open source addons directory fully automated and backed by GitHub, and that would be a huge leg up for our open source presence. We need a bunch of automation to get that stuff up to date correctly, and a scalable system that other devs can participate in.

Categories