SEP 2ND, 2019

Managing 3rd Party Binaries

A simple way to manage binaries from third parties.

When looking over the shoulders of my coleagues, I noticed them being unsure where to install 3rd party binaries ¹.

I propose a simple ² scheme for 3rd party binaries management. Let’s say I want to install k9s.

put ~/bin ³ into your PATH ⁴
create a ~/3rd_party directory
when downloading a 3rd party software create a base directory in ~/3rd_party for it. That would be ~/3rd_party/k9s
download the software into a versioned subdirectory. For example ~/3rd_party/k9s/0.8.4
create a symlink with the name of the executable from the base directory to the subdirectory ⁵:
```
$ cd ~/3rd_party/k9s
$ ln -s 0.8.4/k9s
```
create a symlink from your ~/bin to the 3rd party directory ⁶:
```
cd ~/bin
ln -s ~/3rd_party/k9s/k9s
```

Finally we have:

$ k9s
  -> ~/bin/k9s
     -> ~/3rd_party/k9s/k9s
        -> ~/3rd_party/k9s/0.8.4/k9s

by third party binaries I mean binaries downloaded from the internet, as opposed to programs/scripts which you have created yourself, or binaries coming from your distribution. It can be argued that distribution binaries should be prefered over “3rd party” respectively “upstream” binaries, however this is out of topic for this article. ↩︎
simple both conceptually and implementation-wise ↩︎
modern Linux puts your private binaries into ~/.local/bin. That way installation software can automatically add binaries into that path. The idea would be that ~/.local/bin is in your PATH. I prefer not to do things that way, since
1. ~/.local/bin is “invisible” and I do not want my 3rd party binaries be invisible and 2. because I want to explicitly control, when executables get added to my PATH.
↩︎
this is usually done via ~/.bashrc ↩︎
That way you can easily control which version is the default version you are using and can fall back if the new version doesn’t work. ↩︎
That way the “versioning” concern is isolated strictly inside ~/3rd_party/PRODUCT and doesn’t bleed into ~/bin ↩︎