Zenhack.net

Openshift, Bower and Dependency Bloat

06 Jun 2015

News: Iron Blogger 2 is pretty much ready for prime time! I sent an email out to the list a few days ago. It needs more work, but we can start using it at least. Jeff’s done some great work making the page a lot nicer to look at; check it out. We’ve also managed to work around the problems we were having with livejournal — Damien’s feed is hosted elsewhere, so we’re just using that for now.

Jeff’s initial patch used Bower to pull in the third party styles and fonts the site uses. This… caused some problems.

There are two ways I could have handled deploying the Bower-enabled version of the site onto Openshift:

  1. Add an action hook to pull down the Bower assets during the deploy step.
  2. Commit the Bower assets to the local repository, and push it.

Needing to do (2) is exactly the problem Bower is trying to solve. It’s also what I ended up doing.

The concrete problem is that getting Bower installed on Openshift is a nightmare. I still haven’t actually pulled it off, but from everything I can find it involves rolling a lot of things yourself.

Bower is written in Javascript, and the canonical way to install it is to use node.js’s package manager, npm. At some point npm introduced some new notation for specifying versions of dependencies, which the Bower packages uses. Unfortunately, the version of npm available on Openshift is too old to understand the new notation, so installing bower fails.

I’ve hit a lot of problems like this with platforms that try to be “stable” — I could go off on a long rant about how holding back the versions of your software doesn’t necessarily (or even usually) make for a more functional system, but that’s kindof missing the point:

WHY DO I NEED NODE.JS TO INSTALL A PYTHON APP!?

The problem that Bower solves is not hard. It is in fact easier to deal with manually than deploying bower on all of the platforms I might care about. Pulling in dependencies introduces complexity, and in this situation there wasn’t actually that much of it to begin with. If you’re already writing your server stuff in Node, bower is probably pretty reasonable, but for something that’s python on the backend it’s entirely inappropriate.

There’s a maintenance cost involved in any dependency you introduce — I feel like developers don’t ask themselves often enough: Is this giving me enough to justify the dependency bloat?

In this case the answer is a resounding no. We’ve moved over to using git submodules instead now; it covers 99% of what Bower does for us, doesn’t pull in any additional dependencies (we’re already using git, and Openshift requires it anyway), and doesn’t even require any action hooks or what not to pull in the submodules; Openshift appears to just pull them down automatically. Bower already requires every package to be available via git, so there’s no chance of us stumbling across a package that we can’t use this way, but could have with Bower.

The one disadvantage is we have to download the entire repository for each dependency. This isn’t really a big deal though, and it’s still a huge win over fighting the extra tooling.