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.

PHP

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.

Flags:

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”.

Installation

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

Usage

Once installed, simply invoke composer with the require command:

php composer.phar require vendor/package version

Python

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

Flags

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

Installation

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’.

Usage

Ruby

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.

Flags

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.

Installation

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.

Usage

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

gem install packagename

And you’re done!

Unless.

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.

Node.js

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.

Flags

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).

Installation

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

Usage

Surprise!

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.