Managing packages, directories and PATH in Unix (OSX)

Question

I'm a PhD in bioinformatics, mostly self-taught, and I'm coming to a point where I want to clean up my various directory structures (i.e. my data), but I'm also thinking about how I'm storing the various bioinformatic packages I'm using. Having no formal training and having taken only a single Unix course, there's still a lot I don't know that I assume are taught in "Unix 101" or similar. I did a bit of googling, but I didn't really find answers to my questions, so I thought I'd ask them here. I am working on a Mac, so OSX (Yosemite), if that matters.

When it comes to downloading and installing the various packages I'm using, my current solution is to copy the full downloaded directory to /Users/sajber/software just to have all the files, make (if applicable; sometimes there are ready-made binaries in the downloaded directory) and then copy the binaries to /Users/sajber/bin. I have then set my PATH to include /Users/sajber/bin. I am not using any form of package managing software, so I do everything manually.

How "wrong" is this, and how can I improve it? What do people usually do, is there some kind of standard?

I thought about just keeping all the packages in /Users/sajber/software as previously, but rather add the individual packages to PATH, as in PATH=$PATH:/Users/sajber/software/<package>. When I started out, I initially did this, but then my PATH became this long mess of numerous paths that was hard to change without making mistakes, so I went with my current solution instead. It now occurs to me that I might just change .bash_profile instead, giving each package a separate line in it (as above) for easier access, if this is a "better" solution.

I also have a /Users/sajber/scripts folder for my various Python, R and bash scripts, which is also added to PATH. I have a Git repository in this directory for version control. Is this the way you should do things?

Sorry if these questions are all very basic! I just don't really know what is the standard way of doing things in an Unix environment, being mostly self-taught.

Answer 1

Agreeing that there is nothing wrong with doing it this way, there are pros and cons. I have found it useful to keep a distinction between scripts which I develop locally and programs that I obtain from other places:

• scripts that I develop locally have a change history which I need to refer to, while
• programs that I obtain from other places are maintained by others (with their own change history).

Since "my" scripts are most convenient to update in the places they are run from, then it is helpful (to me, at any rate), to have more than one bin-directory.

Before I became involved in creating packages for my programs, I used /usr/local for the latter, doing

./configure && make && sudo make install

and most programs which use autoconf-related scripts default to this scheme.

Others of course will have their own preferences: do what works best for you.

Answer 2

There is nothing wrong with doing it this way.

Answer 3

This started out as a comment but became too long and detailed...

There is nothing wrong with doing it this way for personal-use programs and scripts (i.e. that are only going to be used by your user-id). In fact, what you are doing is good practice, although you might want to symlink the binaries into /Users/saberj/bin rather than copy them - that way it'll be easier to keep track of where each binary came from (and easier to delete or upgrade them).

Programs that are intended to be used by all users on the system should be installed either as packages (if packages are available) or installed into /usr/local using a tool such as GNU stow, which provides some of the benefits of packaging (including easy uninstall) for unpackaged software.