Phing and Composer, which way around?

Question

I want to use both Phing and Composer for my applications. Phing as the build system and Composer to manage dependencies. But which way around should they be used?

Currently we're installing Phing globally on all servers. Phing is supposed to completely automate the build of our various projects. Just checkout a copy of the project, run Phing with the default target and you should be good to. This also implies that there should be a Phing target in there that calls on Composer to install all dependencies. So, Phing calling composer. But I have been unable to find anything about this setup. There's no ComposerTask or anything similar and googling around doesn't reveal anyone working that way.

But I do see a lot of it the other way around. People using Composer to install Phing as a project dependency.

So, what are the (dis)advantages of each method? Am I trying to do it from the wrong way?

Libbey

FYI: I had the same question. It makes much more sense to me to have the build tool (Phing) call the dependency management (Composer) rather than the other way around. It looks like they added a ComposerTask to Phing since you asked this: phing.info/docs/guide/stable/chapters/appendixes/… – Brieta

Link to ComposerTask above is broken, here is a working link phing.info/docs/guide/trunk/ComposerTask.html – Enunciation

Answer 1

I think the main advantage of installing phing via composer, is that for open source projects it's easier to make sure your users have phing installed that way. Typically in those setups phing is just a tool used by some libraries to achieve some tasks.

The other advantage is that every project can use a different version of phing, which you can't do if you have a system-wide one.

If you use phing to manage your entire project build/setup, calling composer from it might make sense, but the other way around as well. For example you could use composer scripts to fire off the phing tasks after every dependency update. That way a project setup would be:

• checkout
• run composer
• composer runs phing after updating/installing deps
• project is built

I honestly don't know if there is a right answer. You can make both ways work, but by doing it this way you at least skip having to install phing first. Obviously you need to install composer instead, but arguably that's easier and you'd need it anyway.

Marje

I ran into one issue that I think is documented as a Github issue (can't find it right now)...after installing phing as a composer dev dependency, the phing classMap was partially colliding with the classMap from the composer.json file in the app. Threw me off at first. – Snapshot

The dev has to make sure that he has all needed dev/build tools. Your answer is like saying that a C++ repository should contain logic to install a gcc Compiler ("composer installs phing"). The code repository should only consist of the actual code and the build plan. Which means Phing first, composer invoked by phing. Also, you have the hen-egg problem here - Composer can install Phing, but what if someone does not have composer already installed? See, that's why I said dev tools/binaries are a responsibility of the dev when he installs his operating system. – Dahabeah

Answer 2

Additional thoughts about this topic.

Generally Seldaek is right that both are possible. There are arguments for phing first too, though. On the level of build architecture I think composer first doesn't make sense. The build process has broader scope and longer lifetime and should therefore manage the dependency manager, not vice versa.

Furthermore, if you work with Phing token replacement to determine what dependency versions you want to install in which environment, it's close to impossible to go composer first because phing will generate the composer.json and must therefore be installed before composer can run.

Conspecific

This should be the correct answer. A whole build contains these steps (of which some can be optional): checkout, installing packages, testing/validating, compiling, deploying. This is usually managed by some CI butler like Jenkins. Jenkins does the checkout and then invokes some kind of build instructions contained within the code repository (so that a project repository is fully self-contained, inlcuding all required build-information). This would ideally be a phing target (i.e. build.xml). Then Phing takes care of invoking composer, doing cleanups, and finally deploying (e.g. via ssh/rsync). – Dahabeah