{"id":26051,"date":"2016-04-21T11:48:47","date_gmt":"2016-04-21T09:48:47","guid":{"rendered":"https:\/\/mamchenkov.net\/wordpress\/?p=26051"},"modified":"2017-01-31T13:25:28","modified_gmt":"2017-01-31T11:25:28","slug":"adventure-in-composer-private-repositories","status":"publish","type":"post","link":"https:\/\/mamchenkov.net\/wordpress\/2016\/04\/21\/adventure-in-composer-private-repositories\/","title":{"rendered":"Adventure in composer private repositories"},"content":{"rendered":"\n

First of all, I would like to take this opportunity and wish composer<\/a> a happy birthday and many more years to come. \u00a0It’s been five years<\/a>, and the world of PHP has changed so drastically that not many people remember how it used to be before.<\/p>\n

I would have completely missed the birthday if it wasn’t for all the Google searching I did while working on a weird problem. \u00a0But before I get to the problem, let me set the scene.<\/p>\n

The big part of composer success is Packagist.org<\/a> – the repository of almost 100,000 packages<\/strong> (93,572, according to statistics<\/a>, as of this writing, to be precise), which help one to solve pretty much any problem that PHP can be used for.<\/p>\n

As good as the Packagist is, there is often a need for a repository or a package elsewhere. \u00a0Whether it’s a commercial library, or sensitive corporate code, having an ability to store it outside of public eye and handle with the same ease and the same tool as the rest of the dependencies is a very welcome feature.<\/p>\n

Now we are getting closer to what actually happened. \u00a0A while back, I’ve setup deployment and development process for WordPress-based projects. \u00a0WordPress doesn’t support composer natively, but there are ways to make it work. \u00a0Huge thanks here goes to Roots<\/a>.<\/p>\n

So. \u00a0The composer.json<\/em> file was filled with additional repositories and requirements which told composer where from to fetch things, and where to install them. \u00a0Here’s an example:<\/p>\n

\r\n"repositories": [\r\n    {\r\n        "type": "package",\r\n        "package": {\r\n            "name": "wordpress",\r\n            "type": "webroot",\r\n            "version": "4.4.1",\r\n            "dist": {\r\n                "type": "zip",\r\n                "url": "https:\/\/github.com\/WordPress\/WordPress\/archive\/4.4.1.zip"\r\n            },\r\n            "require": {\r\n                "fancyguy\/webroot-installer": "1.1.0"\r\n            }\r\n        }\r\n    },\r\n    \/\/ ...\r\n<\/pre>\n
This got especially useful, when we need to work with commercial plugins, which we couldn’t push to our public repositories, and which we didn’t want to re-distribute with every project.<\/p>\n
So far so good. Fast-forward to a few month ago. We are setting up similar development and deployment process, but now for CakePHP-based projects. Things are much easier, since CakePHP 3 natively supports composer<\/a> for the application itself and for its plugins.<\/p>\n
But we still have the need for private repositories here and there, so we follow the same setup as we did for WordPress. This week, we had an unexpected roadblock, which wasn’t making much sense to me. When trying to pull a CakePHP plugin from a private repository, we’d get a nasty exception like this:<\/p>\n
\r\n$ composer update\r\nLoading composer repositories with package information\r\nUpdating dependencies (including require-dev)\r\n  - Installing qobo\/cakephp-test-foo (1.0.1)\r\n    Loading from cache\r\n\r\n\r\n                                                                                                                                              \r\n  [RuntimeException]                                                                                                                          \r\n  Unable to get primary namespace for package qobo\/cakephp-test-foo.                                                                          \r\n  Ensure you have added proper 'autoload' section to your plugin's config as stated in README on https:\/\/github.com\/cakephp\/plugin-installer  \r\n                                                                                                                                              \r\n\r\n<\/pre>\n
This was confusing. First of all, I’ve never seen this error before. Secondly, I’ve read the README and had the autoloader section in the composer.json as instructed. Thirdly, very similar plugins were working fine.<\/p>\n
Long story short, the issue wasn’t related to whether or not the GitHub\/BitBucket repository was private or public. It was related to how the repository was configured in the composer.json<\/em>. Reading and re-reading composer documentation about Repositories<\/a> finally helped.<\/p>\n
You can have a look at our test setup:<\/p>\n