Composer support

[swalkinshaw]

Ref: #46

This is a basic composer.json file which will let you publish the plugin to https://packagist.org/.

Note that I did this before I noticed you were working on publishing this to the WP plugin directory. Your concern about publishing it there because it isn't a true plugin (it's a "drop-in") also applies to this. Composer only deals with folders so technically wordpress-plugin or even wordpress-muplugin isn't completely valid as the package type.

There is a drop-in installer being developed at https://github.com/Koodimonni/Composer-Dropin-Installer which uses the wordpress-dropin type but since it's not ready yet, we'll stick with wordpress-plugin.

[tollmanz]

Thanks, @swalkinshaw!

Currently, I'm working on a method for installing the plugin as a true WP plugin, but then symlinking object-cache.php to the proper location. Would it make sense for the plugin to be installed using composer then do the symlinking separately? I think that this would work.

[swalkinshaw]

I think a lot of people end up doing that even with older WP plugins like Batcache. Composer is a great improvement over that since it will still manage the plugin itself, then you just have to find a way to symlink it.

In your case, keeping the type as wordpress-plugin makes sense then since it would appear along-side any other WP plugins installed by Composer.

[tollmanz]

Ok...I think this makes sense to add.

In the develop branch, you'll see that I've added some WP CLI commands. Most notably, I've add wp mem install, which simply symlinks object-cache.php into place. After getting this on the WP.org repo, the new install method will be:

wp plugin install pecl-memcached --activate
wp mem install

With composer support, the install method would be:

composer install
wp mem install

Do you see any issues with this?

I appreciate your feedback as I do not use composer with WordPress.

[swalkinshaw]

Nope, looks like a good idea actually. The WP-CLI command is opt-in so even with my intended use-case (the Composer dropin installer), it will work as well.

One minor thing after taking a quick look at the command source. Maybe it's better to use http://php.net/manual/en/function.symlink.php rather than shelling out?

[tollmanz]

Nope, looks like a good idea actually. The WP-CLI command is opt-in so even with my intended use-case (the Composer dropin installer), it will work as well.

Ok...sounds good! One last request, would you mind creating a PR against the develop branch? I'll go ahead and merge it in there. It'll get released officially once I get around to finally releasing this as a plugin (soon I hope).

One minor thing after taking a quick look at the command source. Maybe it's better to use http://php.net/manual/en/function.symlink.php rather than shelling out?

Yes...excellent call! Thanks for the review!

[swalkinshaw]

Sure, I'll re-do this for develop. But I'll actually test this composer.json file locally first. This was mostly off the top of my head copying another one but you never know.

[tollmanz]

Sound great! I really appreciate the help. The Travis CI build should also pass against the develop branch. I've fixed up some errors over there.

[gmazzap]

Thanks @tollmanz (and @swalkinshaw for the implementation).

The only suggestion I can give is that would be easier to use the library with Composer if it had any Git tag.

At the moment, the only way to require the library in Composer is via "dev-branchname" that is:

• slower (as it always does a git fetch)
• gives less control on changes applied
• force to use "minimum-stability" Composer setting set to "dev".

Note that you can use branch aliases to map different branches to different versions.

[tollmanz]

@Giuseppe-Mazzapica To be clear, are you essentially saying that without having any tags in this repo, it makes it more difficult use via Composer? If that is the case, this issue will be resolved when I release version 2.0.0. I'm doing a round of updates now in preparation for releasing 2.0.0. Everything in develop will become version 2.0.0 once merged to master. At that time, I will tag it 2.0.0. Honestly, I have no clue why I never tagged anything before this.

Will that satisfy the concern? If not, I'll read through the linked docs more carefully. On first read, they are very confusing.

[gmazzap]

Are you essentially saying that without having any tags in this repo, it makes it more difficult use via Composer?

Yes.

Will that satisfy the concern?

Yes.

On first read, they are very confusing.

I know. :) Essentially the problem is that Composer tries to resolve dependencies by finding a version of a package that is compatible with all the requirements done in different packages that requires different versions of same package.

For example if a package requires ">=2.0" of a repo and another requires "<=2.0" of same repo Composer understand that 2.0 is the only one that satisfies both.

However, if there's a package that requires "dev-master" (stands for "master" branch of a repository), and another that requires version "2.0.*" of the same repo, Composer is not able to resolve the dependency, even if "master" branch and 2.0 version are the same code, because Composer just don't know that.

Using a branch alias, you essentially instruct Composer that your branch "master" (or whichever) contains the same (or compatible) code of a set of releases.

For example, when you will release version 2.0, by adding to composer.json:

{
    "extra": {
        "branch-alias": {
            "dev-master": "2.0.x-dev"
        }
    }
}

any package that requires version "2.0.*" and any package that requires "dev-master" can happily cohesist and all obtain same version of the repo.

Moreover, before you release version 2.0, you can consider to add:

{
    "extra": {
        "branch-alias": {
            "dev-master": "1.0.x-dev",
            "dev-develop": "2.0.x-dev"
        }
    }
}

This tells Composer that your branch "develop" contains code that is compatible with the versions 2.0.* and your branch "master" is compatible with the versions 1.0.*

The benefit of this, is that consumers can require 2.0.* and obtain code from branch "develop" before version 2 is released, and then obtain code from branch "master" when version 2 is released and branch alias updated accordingly.

All that without forcing consumers to change anything in their code.

[tollmanz]

This is a fantastic explanation! This is such much clearer than the docs.

Moreover, before you release version 2.0, you can consider to add

If I add those suggested changes, would I update dev-master to 2.0.x-dev after I officially release 2.0.0 and merge develop to master?

[gmazzap]

This is a fantastic explanation! This is such much clearer than the docs.

Thanks :) It tooks some time before I fully understand that part of Composer docs... glad to make it more clear to someone else.

If I add those suggested changes, would I update dev-master to 2.0.x-dev after I officially release 2.0.0 and merge develop to master?

Yes, exactly. Because after merging "master" branch will contain 2.0.x compatible code.

[tollmanz]

Great! Thanks again. I'll go with that suggestion.

[tollmanz]

For reference, this work is completed in #66.

[gmazzap]

Perfect :)

Can confirm that using following composer.json

{
    "minimum-stability": "dev",
    "repositories": [
        {
            "type": "git",
            "url": "git@github.com:tollmanz/wordpress-pecl-memcached-object-cache"
        }
    ],
    "require": {
        "tollmanz/wordpress-pecl-memcached-object-cache": "2.0.*"
    }
}

I was able to fetch the repo via Composer from develop branch.

When you'll merge develop, release version 2 and update branch alias, with no modification on code above I'll be able to fetch repo from master branch.

Many thanks for your commitment.