A quick guide to making your software installable

This post is a blatant excuse to give myself the opportunity to vent some steam  Some bioinformatics software packages/pipelines are notoriously difficult to install; others have just given no thought whatsoever to environments other than their own.  Here is quick check list of “DOs and DON’Ts” – well, in fact it’s mostly DON’Ts.

When considering the people who will install your software:

1. Do not assume, under any circumstance, that we have root access.  We may very well have to obey the orders of a paranoid sys/admin who does not allow us root access.  We have to try and work round that.
2. Do not assume that our system is in any way standard.  It won’t be.  It isn’t.  It never has been.
3. Do not assume we have the latest anything.  We might do, but it won’t be where you think it is (see (1)).
4. Do not assume that our Perl, Python etc libraries are in standard places.  See (1) above – we probably had to install them somewhere we could write to.  Yes, we know about $PERL5LIB and $PYTHONPATH – does your install script?
5. Do not assume the system (/usr/bin/) Perl, Python etc is the one we use.  See (1) above – we probably had to put newer versions of Perl, Python etc somewhere we could write to.
6. Do not assume, just because it’s not in our PATH, that we don’t have it.  There are all sorts of reasons why we might have something, but not put it in our PATH.
7. Don’t force us to install, or link, software into a sub-directory of your software.
8. Don’t force us to download, or link, large databases into a sub-directory of your software.
9. Don’t assume the user, or the server, has internet access.
10. Just because you are a developer, doesn’t mean we have all the *-dev packages installed.  Don’t assume we do.
11. Don’t write an install script that installs something else which installs something else which installs something else etc etc.  If you have multiple dependencies, give us a separate script for each one and let us decide how, when and where it is installed.
12. We will absolutely, 100% shut down and remove anything that tries to gather statistics and “call home”.  If this feature was a person, we would punch it, it makes us that angry.   Just. Don’t. Do. It.
13. Do not think, for one second, that providing a VM circumvents any of these problems – it doesn’t.  VMs are occasionally useful, but ultimately, we will need the software on a local server – and the day our sys/admin lets us put your VM onto our network is the day hell freezes over.  And no, AWS is not the solution.  Not at those prices.
14. DO – write a good step-by-step tutorial on how to install all of the dependencies and your software.  It’ll take time, and you will really not want to do it.  But good devleopers write good documentation.  So go write some.

facebook

twitter

Tweet

google+

linkedin