Allow configurable vendor path for Composer packages

[iknowthis]

The current install steps assume Composer is run inside the plugin folder and installs packages in /Plugin/CakeResque/vendor. This change allows you to also install the CakeResque plugin with Composer. The plugin and all its dependencies are installed in the default Composer location (/Vendor for CakePHP). The default behavior stays the same as it was before.

[coveralls]

Coverage remained the same when pulling 837632a2673aa860415fad47bb7632e2b1cd1ac0 on brism:vendor-path into 7f581a7dd962a1bdccad2aacc6199e1ed2848b0e on kamisama:master.

[wa0x6e]

What's wrong with leaving the Plugin in the /Plugin folder ? Even if installed with Composer, outside the /Plugin folder, the package should still be installed automatically inside the /Plugin folder.

That's the purpose of these lines in composer.json

"type": "cakephp-plugin",
"extra": {
    "installer-name": "CakeResque"
}

[iknowthis]

Nothing wrong with that; that's how I'm using it too.

The difference is that I'm not installing the dependencies inside the plugin in /Plugin/CakeResque/vendor. Since you provided the CakeResque plugin on Packagist as well as the dependencies, I'm installing all of them with Composer.

My composer.json:

{
    "config": {
        "vendor-dir": "Vendor/"
    },
    "require": {
        "cakedc/migrations": "2.2.*",
        "cakephp/debug_kit": "2.2.*@dev",
        "kamisama/cake-resque": "3.3.*"
    }
}

The CakeResque plugin is installed at /Plugin/CakeResque as it should be, and the dependencies are installed in the default Composer location /Vendor.

/Vendor/
    composer/
    kamisama/
        monolog-init/
        php-resque-ex/
        php-resque-ex-scheduler/
        resque-status/
    monolog/
    psr/

These can be autoloaded and used along with any other packages I add with Composer.

So, my change just allows you to specify a different location for Composer's packages (like the default one /Vendor), instead of assuming they are in /Plugin/CakeResque/vendor.

By the way, thanks for the plugin and thorough docs. I'm just getting started with Resque and jobs, and was happy to find someone had made a good adaptation for CakePHP.

[wa0x6e]

I though like that too, for the earlier version of CakeResque.

The problem with the sharing dependencies approach is that each Plugin have their own minimum required version.

e.g: after updating CakeResque, you should always do acomposer update, as new features in CakeResque often comes with some new options in the dependencies. If the dependency is shared, you simply can't update it carelessly without checking that the new version works with all the other plugin.

I think Composer was written with that in mind, and the composer.lock file is enforcing that.

[iknowthis]

That's a good point. I haven't run into the problem of packages needing different versions yet, but it's certainly possible.

I was hoping to avoid mixing Git submodules and Composer packages if possible. It seemed cleaner to me to do one or the other, and I like the way Composer works. However, I'll take a look at "The Pro Way" from your installation docs, where CakeResque is a submodule and the dependencies are installed by Composer inside the plugin.

Thanks!

[wa0x6e]

I was hoping to avoid mixing submodule and composer packages too, but it seems impossible, due to the minimum version.

[joshuapaling]

I'm coming up against the same issues, trying to install this plugin itself via composer.

This pull request should definitely be merged. It allows the user to configure the vendor dir, and it defaults to the existing vendor dir (inside the plugin), meaning people who want to continue using this plugin as a submodule can do so without changing anything.

The whole point of composer is for it to handle the updates automatically, figure out the dependencies and remove the need for git submodules, manual updates, and so on.

There are a number of ways to resolve conflicting dependencies with composer, if and when you come up against them. For example, with this plugin, if a user did come up against conflicting dependencies, then they could install it as a submodule - and that would still work after this pull request is merged, since it allows the vendor dir to be configured.

But most of the time, people won't come up against dependency management issues, and when they do, they'll often be able to resolve them just by updating their other plugins, also.

[joshuapaling]

Read this:

http://stackoverflow.com/questions/12656982/resolving-dependency-hell-with-composer

That's another way of resolving conflicting dependencies with composer. Conflicting dependencies are a necessary evil of all dependency managers. But, you don't worry about that because the benefits of Composer by far out weight the downsides.