Adventure in composer private repositories

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

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

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

As good as the Packagist is, there is often a need for a repository or a package elsewhere.  Whether 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.

Now we are getting closer to what actually happened.  A while back, I’ve setup deployment and development process for WordPress-based projects.  WordPress doesn’t support composer natively, but there are ways to make it work.  Huge thanks here goes to Roots.

So.  The composer.json file was filled with additional repositories and requirements which told composer where from to fetch things, and where to install them.  Here’s an example:

"repositories": [
    {
        "type": "package",
        "package": {
            "name": "wordpress",
            "type": "webroot",
            "version": "4.4.1",
            "dist": {
                "type": "zip",
                "url": "https://github.com/WordPress/WordPress/archive/4.4.1.zip"
            },
            "require": {
                "fancyguy/webroot-installer": "1.1.0"
            }
        }
    },
    // ...

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.

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 for the application itself and for its plugins.

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:

$ composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Installing qobo/cakephp-test-foo (1.0.1)
    Loading from cache


                                                                                                                                              
  [RuntimeException]                                                                                                                          
  Unable to get primary namespace for package qobo/cakephp-test-foo.                                                                          
  Ensure you have added proper 'autoload' section to your plugin's config as stated in README on https://github.com/cakephp/plugin-installer  
                                                                                                                                              

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.

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. Reading and re-reading composer documentation about Repositories finally helped.

You can have a look at our test setup:

CakePHP plugin installer requires the autoload section in composer.json.  But, when the repository is of type “package“, for some reason, the autoload section is ignored altogether.  The RuntimeException “Unable to get primary namespace for package” is thrown by cakephp/plugin-installer (src/Installer/PluginInstaller.php line 274).  The problem is not actually in the cakephp/plugin-installer, but somewhere in the composer.  Maybe it’s intentional or maybe it’s not.  I didn’t have the time to investigate and understand it further.

Switching the repository to type “vcs” fixes the problem.  It also simplifies the composer.json file and removes the need for multiple version definitions, as now composer is using BitBucket/GitHub API to fetch available versions.

CakeFest 2016

I’ve just purchased my ticket for CakeFest 2016! Feeling super excited … Whoop whoop! :)

I’ve attend quite a few events in the last 15-20 years, ranging from generic TEDx, through startup and entrepreneur, generic technology, web development, PHP, and software specific ones.  CakeFest 2014 back in Madrid, Spain was one of the most memorable and is definitely in top 3 of my all time favorites.  So I’m excited about the opportunity to do it all over again, this time in Amsterdam, Netherlands.

If you are involved at all with CakePHP framework, I strongly recommend you get your ticket, while it’s still at the “blind bird” price of $150 USD for the two day conference event.  If you are very new to CakePHP, you might want to consider the workshops as well, but make sure you do the main conference no matter what.

CakeFest 2015 Presentations

CakeFest 2015 Presentations – a convenient list of all CakeFest 2015 presentations in one place.  Not sure how permanent the site is (I have a feeling this is a quick CakePHP coding experiment during the event), so hurry up and grab the links just in case, until something better comes out.  There were some really good talks by the looks of it.  Too bad I didn’t make it this year.

Claim to fame : phinx LONGBLOB

My largest claim to fame in the Open Source software just got merged in – a pull request to the phinx project, adding support for MySQL’s LONGBLOB (as well as TINYBLOB and MEDIUMBLOB).  Phinx is the PHP tool for database migrations.  It’s used, among others, by the CakePHP 3 framework.

The patch itself was rather simple and I was surprised that it hasn’t been done by someone else earlier (there was an open issue requesting this for more than a year).  Phinx already had support for BLOB, and for TINYTEXT, MEDIUMTEXT, TEXT, and LONGTEXT.  So practically all I had to do was a bit of copy-paste and find-replace.  Gladly, there were some unit tests in place already, preventing me from breaking a thing or two.

What I found interesting though, wasn’t the patch itself, but the support of the CakePHP community (thank you guys!).   Every few days someone (even core CakePHP developers) would “thumbs up” the pull request to draw the attention of the maintainer to it.  Some people pulled the branch and tested it.  Some wrote comments.  That was awesome and quite inspiring!

 

 

CakeFest 2014 : a look back

Disclaimer:  I’ve written this post a few days after I came back from CakeFest 2014.  Unfortunately, it is unfinished, and by now I have completely lost hope of ever finishing it.  My main excuse is that the first day after CakeFest was my first working day at my new job, which completely and totally consumed me for a few months.  And now, it seems like CakeFest 2014 was a few decades ago.  Mostly I wanted to do two things here: list all the talks with videos and slides, which has probably been done by other people by now, and tell everyone that this was one of the best events I’ve ever attended.  For those who haven’t been to one, I strongly recommend getting a ticket to CakeFest 2015, which will take place end of May in New York, USA.  End of Disclaimer.

 

It’s been a week since I came from Madrid, where I’ve attended CakeFest 2014, a conference dedicated to CakePHP framework.  Now that I’ve caught up on sleep, calmed down, and cleared out my mailbox, I have a few minutes to look back at the event and share my thoughts and impressions.

CakeFest2014

For those of you who are too busy to read the whole thing, here’s the executive summary.  I had very high expectations of the conference way before I went.  I knew there will be one or two core developers.  I knew that there were previous events before.  And I do usually expect high quality stuff from the CakePHP community.  But as I high as my expectations were, the event went through the roof!  It was an absolutely amazing couple of days, where I met a lot of cool people, learned a lot, and had plenty of fun!  If you missed this year’s conference and you are involved in any shape or form with CakePHP, make sure you attend the next year one.  Start making your arrangements now.  You can thank me later.

Now for the long story…

Continue reading “CakeFest 2014 : a look back”

PHP tags – once and for all. Yet again.

For those of us who have been using PHP since the early version 3 days and such, here is a modern day refresher for PHP tags:

If a file is pure PHP code, it is preferable to omit the PHP closing tag at the end of the file. This prevents accidental whitespace or new lines being added after the PHP closing tag, which may cause unwanted effects because PHP will start output buffering when there is no intention from the programmer to send any output at that point in the script.

And from the comment on the same page:

Since PHP 5.4 the inline echo <?= ?> short tags are always enabled regardless of the short_open_tag (php.ini) setting.

For me personally, closing PHP tags are a part of muscle memory.  I’ll have to unlearn that, I guess.  And in regards to the inline echo tags, I was under the impression that they are being phased out together with the other short tags (<? … ?>).  Apparently, I was wrong.  They are here to stay.  Which explains why there are in PSR-1, PSR-2, and in CakePHP 3 (which requires PHP 5.4.16 and fully adopts PSR-2) in particular.

Compatibility Breaks in CakePHP 3.0

Mark Story goes over a few reasons of why CakePHP 3.0 breaks compatibility in this blog post.   If you are working with CakePHP or involved in any large system that lives forever, you should read those in detail.  Otherwise, here is an overview:

  • PHP has changed
  • Ideas that didn’t work out so well
  • Outdated implementations
  • Improve consistency

Also, if you are working with CakePHP, you should attend the CakeFest 2014 event next week in Madrid, Spain.