My Drupalcon LA, part 1: Sessions and BoFs
Drupalcon LA was a unique experience for me in many ways. It was the first Drupalcon I’ve gone to that I didn’t expect a Drupal 8 alpha, beta, or release candidate. Drupal 8 itself no longer felt like a strange far off future but here, just right around the corner.
When LA was announced I was sitting in the sprint room at Austin working on Examples module. My first reaction was, “Yeah, I’ll skip that...unless if I’m speaking.” I’ve been to LA before on other business trips and it’s simply not my kind of place. Having been fortunate enough to go to two Drupalcons already, I saw less of a need to go this time.
And then I got two sessions accepted
Speaking changes how you approach a Drupalcon. You’re no longer just an shopper in a informational candy store, you have a job to do. It preoccupies everything you do at the ‘con. If you’ve ever done speaking professionally, then you know, it’s really hard work. You can spend entire work weeks refining your slides, your sentences, and going over every single image. I typically practice my sessions the previous night, or even the night before that if the session is new enough.
The topic of my first session was somewhat niche, even for a core conversation. Considerable amounts of fear, uncertainty, and doubt were created during Drupal 8’s exceptionally long development history. In Fighting Core FUD: We Need a Contrib Champion, I suggested creating new role, a Contrib Champion to help mitigate this and other issues.
My second session was given at the end of the con, right before the closing session. I’ve given Capture the (Drupal 8) Flag several times before. In it I go through what led me to port Flag module to Drupal 8, how I approached the project, and the lessons I’ve learned.
Aside from volunteering and some booth time for FFW, I didn’t spend much time at sessions themselves. Like all Drupalcons, the sessions were recorded and I could go back to them at any time. For the most part, I tried to see as many Birds of a Feather sessions as possible. BoFs are where some really interesting things happen. Sometimes a BoF is a session that didn’t get accepted, or it’s a meet-up for people with similar interests or concerns, or a time slot for core devs to get together and figure out key problems. I saw all three at LA.
Anyone that’s been to a Drupalcon before can tell you, sessions are the least interesting thing to see. Many unaccepted sessions or meet-ups end up as Birds of a Feather sessions, or “BoFs”. The most interesting BoF I attended was simply titled “Composer and Drupal”. I had wanted to learn more about Composer, but I didn’t actually look into or think about the session more than that. Soon I found myself in a room of core developers trying to hash out a rather difficult problem.
Drupal 8 uses Composer to manage internal dependencies and build two key items: vendor/ directory to house 3rd party code, and an autoload.php. Drupal 8 (at time of this writing) has a weird setup compared to other modern PHP projects. Instead of having vendor/ in the root directory of our project, we have it in core/vendor/. This was done to make it easy to update core files, but required some odd hacks to make it work. Moving vendor/ out of core/ however, presented other challenges. Presently, we keep a large body of 3rd party code in the Drupal repository. This is bad practice, but it does make things slightly easier for new developers and site builders. If we wanted to keep all that code out of the repo, we’d also have to modify Drupal.org’s build scripts for creating Drupal tarballs. This was seen as the best compromise.
The more interesting discussion was what followed. Drupal 8 doesn’t use Composer to manage module dependencies. Instead, we have our own code that managing installing, enabling, and uninstalling modules. In modern PHP, this is a duplication of effort. Composer is more than capable of performing this task, and it does it better. Many of the largest modules, such as Drupal Commerce, already use Composer to build their own dependencies. This, unfortunately, means vendor/ directories inside of modules, gumming things up further. Shouldn’t we all just be using one Composer?
However, once you pull out one thread…
Using a single Composer for all of Drupal -- both core and contrib -- makes a lot of sense. It also introduces some rather sticky problems for site builders. Composer is a command line utility. It writes to the file system and creates a key autoload.php file. While you can write a Web UI that does this, it introduces fundamental security holes. Many shared hosting providers, however, do not provide CLI access.
A single Composer also puts the entire Admin > Extend page to question. If we use Composer to install modules, what’s the point of Admin > Extend? We’re obviously too late to act on any of this for Drupal 8, but it is something to think about for Drupal 9.
Coming in part 2...
There was more to say about Drupalcon LA than just sessions and BoFs. In part two I’ll talk more about LA, the general feel of the con, and some thoughts on sprinting.