Simplify travis install of bats

[jasonkarns]

I don't think there's much value in running the bats install script. Rather, bats can just be cloned and executed from the clone. Indeed, this is what most of the rbenv projects do when running on travis.

This also (marginally) speeds up the test suite since there is no need to run the bats install script or remove the one-time-use clone.

[ztombol]

This .travis.yml, and the installing of Bats, comes from another project of mine where I needed bats to be in $PATH. It's a convenient solution, but not everybody may like/need it.

I could have just added the bin directory of the cloned repository to $PATH, but I didn't want to have to do that for every source built dependency that I needed in $PATH.

before_install:
  - git clone https://example.com/repo/app-a
  - git clone https://example.com/repo/app-b
  - git clone https://example.com/repo/app-c
before_script:
  - export PATH="${HOME}/app-a/bin:${PATH}"
  - export PATH="${HOME}/app-b/bin:${PATH}"
  - export PATH="${HOME}/app-c/bin:${PATH}"

So I decided to install such dependencies with the prefix ~/.local and add only ~/.local/bin to $PATH.

before_install:
  - ./script/install-app-a.sh
  - ./script/install-app-b.sh
  - ./script/install-app-c.sh
before_script:
  - export PATH="${HOME}/.local/bin:${PATH}"

I also put the install logic into a shell script (as recommended for complex commands such as installing software from source or implementing complex build steps) to keep .travis.yml clean and make it simple to share it between projects.

If I need to add a dependency that I have already used in another project, I just have to copy the install script and add it in .travis.yml where, if this is not the first source built dependency, I already have $PATH containing the common bin directory. Think of it as a crude way of package management.

Obviously the more source built dependencies a project uses the more benefit this approach has. And installing, copying usually just a few files, has very little overhead comparing to downloading, building, and testing the project.

It's a tiny bit of overhead for a tiny bit of convenience. Not everybody may like it or think it worths the hassle. I haven't had that many projects to actually see the real benefit of sharing yet. I just happened to use it elsewhere and used it here as well.

I'm open to changing this with your patch if you still think that's better. :)

Advantages:

• share dependency install logic between projects
• easily add source built dependencies to $PATH

Disadvantages:

• overhead of copying
• not everybody may like it