using composer to require file shared by multiple sub-directories

Question

I have a GoDaddy shared hosting site.

The root folder is html

I use this as a testing server so html has several sub-directories like /site1, /site2, /site3.

I'd like to install and use the parse.com PHP SDK and am following this guide to set it up

I have installed composer on the server:

-bash-4.2$ curl -sS https://getcomposer.org/installer | php
#!/usr/bin/env php
All settings correct for using Composer
Downloading...

Composer successfully installed to: /home/content/08/555555/html/composer.phar
Use it: php composer.phar

I have created composer.json with the below content:

{
  "require" : {
    "parse/php-sdk" : "~1.1.*"
  }
}

As I understand it, I should put this file in my project folder which seems to mean the root folder of the site like site1 in my example, then cd to that directory and "Execute composer with the install parameter".

However, I want to be able to include the parse SDK in each site like /site1, /site2, /site3.

Do I need to add a composer.json to each site folder, put the parse folder in html and change the path to "../parse/php-sdk" : "~1.1.*", or is there a better way to set this up?

Answer 1

Composer is not built to act as a package manager, it is a dependency manager. The difference is that a package manager installs packages in a central location for everyone to use, while a depencency manager installs locally for only one application.

Composer COULD install packages into a central location as well: composer global require vendor/package, and it creates an autoloader there that could be used by an application. The problems start when it comes to multiple applications using more than the centrally installed packages.

First problem: Updating. Going forward to a significant new release (i.e. not only bugfixes, which should be backward compatible, but new features and possibly incompatible changes in the internal workings of a package) might require some adjustments in an application. Now with a central package being updated, such adjustments have to be done in all applications at the same time. It's not impossible to do, but usually it inhibits the update because nobody wants to do the extra work in all the other applications.

Second problem: When using a package that should only be installed for one application locally, but requires components of a package that is installed centrally, Composer will not recognize this installation. You'd get this package installed twice instead - and the local installation need not be of the same version than the central installation - this will lead to all kinds of possible incompatibility problems, that are really hard to debug, because suddenly the order of autoloading affects the possible outcome.

While it sounds like a bad idea to redundantly install the same packages even in the same version multiple times per application, because it is a waste of file space, the opposite is true: File space is cheap, working applications are considered worth more than the cost for duplicate files on the hard drive. And the ease of managing and updating the dependencies a single application are hard to match with a central installation.

PEAR used the central approach. It cost the maintainers ridiculous amounts of work to guarantee backwards compatibility with every single release of a package, to the point where regular PEAR packages even today are backwards compatible to PHP 4.0. Nobody likes to use PEAR today, didn't like to use it even before Composer came to life. I'd take this as a strong indicator to not install packages in a central location.