Tag: packages

Custom Go package manager

I was working on a Go project with no modules support and introducing the modules was not an option at the time. All dependencies were installed by go get. When breaking changes were introduced in some packages, the builds started failing.

A simple way to quickly fix the issue was to write a very basic package manager which could get dependencies by the specified version (which go get does not support in GOPATH mode).

A package list can be a simple file which declares packages line by line. If no version specified, go get will be used. If a release version, commit hash or branch is specified, a git clone and checkout on the specified version will be invoked.

github.com/gorilla/mux@v1.7.2
github.com/go-playground/validator
github.com/apixu/apixu-go@0fe1e52

I wrote a Bash script which parses the file and handles the process for each of the two cases.

#!/usr/bin/env bash

FILE=$PWD/packages

[[ -z "${GOPATH}" ]] && echo "GOPATH not set" && exit 1;

GOSRC=${GOPATH}/src
[[ ! -d "${GOSRC}" ]] && echo "${GOSRC} directory does not exist" && exit 1;

while IFS= read -r line
do
    IFS=\@ read -a fields <<< "$line"
    pkg=${fields[0]}
    v=${fields[1]}

    echo ${GOSRC}/${pkg}

    if [[ -z ${v} ]]
    then
        go get -u ${pkg}
    else
        PKGSRC=${GOSRC}/${pkg}
        rm -rf ${PKGSRC}
        mkdir -p ${PKGSRC}
        cd ${PKGSRC}
        git clone https://${pkg} .
        git checkout ${v}
        cd - > /dev/null
    fi

    echo
done < "${FILE}"

If it’s not broken, fix it before it will be

I’ve recently read a discussion on server software upgrades, and someone was recommending not to upgrade if you don’t have a problem.

My approach is a little bit different, as in I advise you to upgrade from time to time (at least) your OS and packages. In “the real world” it’s not often easy to do this, but if context allows, you should do it. You should prevent unwanted situations, instead of fixing them after they’ve done damage, and maybe suffer consequences.

A basic approach (in a decent context) would be to make upgrades in test environments. After you make sure you’re ready for production upgrade, redirect traffic to some new temporary machines before updating main machines. Of course, if you have your own load balancer instead of a DNS one, it’s easier to do this. Don’t upgrade directly on production, don’t assume nothing could go wrong. Back up data before!

The same goes for code libraries. I’ve seen upgrades being ignored because “we don’t have time now”, and ignorance. Then a moment came when they were forced to make the upgrades, because new libraries were depending on new versions of the existing ones. You should have seen the “joy”, and the bugs which followed in production, as there was no time to test everything as it should have been.

Upgrades can be a pain, they can crash, they can take time, new packages can have issues. However, this is not a reason to ignore them.