Composer

[Milano]

If you are PHP developer, you probably hear about Composer - Dependency Manager for PHP, it's awesome and it makes PHP so much easy and interesting to work with. The PHP world is moving with it, if you need libraries for your project, just one simple command and BOOM, the files will be downloaded to your project and available to use immediately, forget about libraries version, forget about include or require the files (autoload things), you are ready to rock'n'roll. I want to use it on my add-ons but having vendor folder for each add-ons is not a good idea, it does not make any difference from the old way. As a developer, what are your thoughts about this?

 

[Arty]

Its great for open source projects for fetching and automatically updating third party modules.

But XenForo is not an open source project.

 

[tyteen4a03]

Its great for open source projects for fetching and automatically updating third party modules.

But XenForo is not an open source project.

XenForo does use third-party modules; I don't see why xF (2, at least) can't benefit from Composer.

 

[Sim]

I do a lot of work in Laravel, which is all composer and PSR-4 autoloading and such - and it is definitely a huge step forward. I have already published quite a few of my own packages on https://packagist.org/ which I pull into my various projects as required (and some are being fairly widely used by others as well).

I did actually go through the exercise of extending the XenForo autoloader functionality to allow it to autoload composer vendor autoload files as well - with the intention of packaging my XenForo addons as composer-installable packages with auto-dependency management using composer.json ... but given that extending the autoloader functionality does require some (minor) tweaks to the core code (specifcially adding two lines to each of the index.php, admin.php, deferred.php etc files in the root directory) - I decided it wasn't worth the effort and have gone back to building plain-old XenForo addons.

I do utilise 3rd party (and my own) composer packages in my addons, and the current way I'm managing that is to have a simple composer.json file in my addon root, which I use to create the vendor directory - from which I then include the autoload files in my init_dependencies routine. I store the entire vendor directory in my source control (which I wouldn't normally do for a composer-built project) and publish it directly to my production server rather than running composer update after deploying my addon.

The main downside for managing things this way is if multiple add-ons use different versions of the same package, there could potentially be conflicts (right now I have two packages which both use Guzzle HTTP client, but one uses Guzzle 3.x and the other uses Guzzle 5.x, which can both be in use at the same time due to different namespacing, so it's not actually an issue, but it could potentially be if I had two packages using Guzzle 4.x and 5.x).

I think being able to build XenForo addons as composer packages would make life a lot simpler - although the nature of addons with their xml definition component does make things more complicated since you would deal with that carefully - especially in regards to version changes.

But XenForo is not an open source project.

Doesn't matter - it could still use Composer to manage third party dependencies, such as Symfony.

However, given that XenForo is a complete ready-to-run package and not an open source group of components, it is questionable whether having composer as the basis for "building" a XenForo application is sensible. More likely, we would still need to have a downloadable package of files that is ready to run without requiring composer to be installed on the machine.

Either way, I'll be interested to see what direction they choose to go with this.

I think moving to standard PHP namespacing (explicit namespace declarations using backslashes) and PSR-0 or PSR-4 autoloading would be a very good first step - just for consistency with the rest of the world (I believe ZF2 now uses PSR-0 anyway).

 

[tyteen4a03]

I think the way to do this would be to run composer via a PHP script (i.e. on addon install).

As for dependency hell, I'd like to see the xF team overcome this.

 

[Sim]

The other important factor to consider with addons is that some people charge for their addons and aren't happy to host their code on GitHub or Bitbucket with a Packagist definition for composer-based installation.

But I would really like to see some kind of dependency management system for addons (ie the dependencies of the addons, not the addons themselves) added to the core.

 

[Milano]

I think the way to do this would be to run composer via a PHP script (i.e. on addon install).

As for dependency hell, I'd like to see the xF team overcome this.

I tried this and it worked (with few changes) http://stackoverflow.com/a/25208897, tested with a single package.

 

[tyteen4a03]

The other important factor to consider with addons is that some people charge for their addons and aren't happy to host their code on GitHub or Bitbucket with a Packagist definition for composer-based installation.

But I would really like to see some kind of dependency management system for addons (ie the dependencies of the addons, not the addons themselves) added to the core.

I don't think a valid repo path is required for composer install...?

I tried this and it worked (with few changes) http://stackoverflow.com/a/25208897, tested with a single package.

Interesting hack.

 

[Sim]

I don't think a valid repo path is required for composer install...?

It is if you want to automate the installation process.

If you end up just manually downloading and installing add-ons just so that you can run composer install on them, what's the point of using composer?

Unless I'm misunderstanding what your approach for installing addons is?

 

[Luke F]

Disregarding the fact that it doesn't suit private code, it also doesn't suit shared hosting (which I imagine is the bulk of XF's market) - where there's often nowhere private to put PHP files and where people don't want to be touching any CLI stuff.

It would be a mammoth task to hack in the XF deferred system, a GUI, and the XF auth system - all of which would be necessary

Composer in its current form really isn't suited for traditional packaged scripts like XenForo, rather only for open source scripts targeting people with PHP skills, and proprietary systems.