Adventures in Engineering

Prior Assumed Knowledge

I often set aside Sunday afternoon to tinker with side projects or learn something and surprise surprise this involves installing new stuff!

I used to play with python, but I don’t very frequently any more. I used to hack php but sadly I’m doing that less and less these days too. As time and tech flies by I fall behind on the current hip way to install things.

The installation documentation for your package or tool is the second most important feature (second in my opinion only to the “what does my package do” stuff). Missing the installation docs, or having vague instructions is the easiest improvement you can make to getting more people to use your package.

Most installation instructions tend to have a download, make/compile and/or install associated with them (whichever may be appropriate). Most however, assume some prior knowledge about a languages preferred package management tool. This is fine for many, but for people like me it’s not particularly helpful – especially in the python world (see below).

I’m noting here some hopefully helpful tips for future reference when I return to tinkering in $language.


My good ol’ friend PHP used to be a .zip download and/or a git clone. And then along came composer and away went many/most/some of our packaging problems.


Look out for composer.json in the root of the project. Of specific importance is the (often first line) “name” field in the JSON object – this is the string you’ll reference to install the package. Expect it to be in the format of “vendor/packagename”.


I personally remember this one liner from the number of times I’ve installed composer!

curl -sS | php

For everything else (or perhaps you use windows) there’s the intro docs for composer


Once installed, simply invoke composer with the require command:

php composer.phar require vendor/package version


Python was the first language I learned and I still love it (albeit use it infrequently at best). When tinkering with python I usually get lost at installation/debugging and give up an hour later. Thats probably due to the fun involving distutils and setup_tools and distribute and distutils2 and easy_install and packaging and pip and eggs and wheels… And all the other packaging fun that Dr Keith-Magee discussed at his talk at PyConAu 2014.

P.S. Thank you Katie helping clarify the state of play with packaging and for introducing me to this talk!

TL;DR Use pip


Keep an eye out for in your project’s root directory.


Good news everybody! You don’t need to install anything. Well other than python of course (but for sanity sake I’ll assume you’ve got that already).

You can however (and probably recommended) use PIP to install packages too. Grab pip from your OS’s favourite package manager, often under the package name ‘python-pip’.

Or, you can follow the install details.

Or you can upgrade to the latest python 3.4 where pip is packaged by default. Yay!


To install from source you can

python install

To install using pip, simply

pip install packagename

Checking of course that the project exists on first.


I very rarely use ruby, other than to install the heroku toolkit and a myriad of dependencies. It is however spectacularly easy to use (and even easier to go wrong w/ dependencies and versions in my experience). Most of that boils down to which ruby env you’re using and that’s rant for another day.


Look out for the *.gemspec file (where the wildcard is the package name). As with most packaging & distribution tools its the package name you care about.


With OSX ruby gems was already installed. If not however your favourite package manager will probably have ‘ruby gems’ as a package, or you can install from the docs.


It’s a familiar pattern – I even guessed this one in my sleep the first time around.

gem install packagename

And you’re done!


There’s a Gemfile.

bundle install

Which installs whatever is defined in the Gemfile.

And then you then run bundle exec <command>

… which for rails apps would be bundle exec rails server

… and for anything else I wish you good luck and leave you here.


My experience of node is debugging a way to get a javascript library added to grunt. Yup, fun times =D The tool of choice however is npm (node package manager) and it comes installed with node itself.


package.json is the file to look out for, and it resembles composer.json from PHP. (On a technicality composer was inspired by npm so really the resemblance should be reversed).

As with composer you’re looking for the “name” field in this file (it’s often the first line so it should be easy).


NPM comes packaged with node so there’s usually no need to install it. You can however (quite entertainingly too) use npm to install npm globally:

npm install npm -g



npm install packagename version

And you’re done!

Importantly however you can add a -g (global, as above) which will install as a cli tool across all environments (and you’ll probably need sudo for this). I find it handy when installing a tool and not a package written in node.

Devtols & OSX.

OSX does some funny things with ruby versions & it has some tools installed by default. I’d recommend browsing this helpful writeup for an overview.


Add comment