Editing Advanced Installation (section)

=Keeping your stuff separate=
A user may add his own programs and recipes to the Madagascar system. He may also create his own computational examples, data, and locked figures for testing. All of these components can be placed in their default locations, but it is not necessary to make them public. To keep these items private simply do not add them to the repository.

However, it might be desirable to keep these components in separate places. For example, if you keep your private programs in RSFSRC/user you will have to remember to make a copy somewhere else if you ever want to delete the Madagascar installation to perform a fresh install. Yup, I deleted all my programs that way once. Good thing I had a back up! Fortunately, it is easy to keep each of these components in a separate place if desired.

==Keeping programs separate==
User programs are ordinarily kept in a subdirectory of RSFSRC/user.  However, if you want to keep your programs separate all you have to do is put your subdirectory somewhere else and make a link to it in RSFSRC/user:
<bash>
ln -s path_to_my_programs $RSFSRC/user/my_programs
</bash>
The additional instructions above for "multi-user installs" are for the case where the other users do not have write access to RSFSRC.  However, if you have full write access and only want to keep the programs in a separate place the link is the only thing you need.

===Problems when symbolic linking and using SVN=== 
If you decide to use a symbolic link e.g. "ln -s ..." as above, you will have difficulties checking in your code into the SVN repository.  SVN typically does not follow the symbolic link but will only the save the symbolic link.   

See this answer from Stackoverflow (http://stackoverflow.com/questions/24850844/follow-symlinks-in-svn)


<blockquote>


If I understand your problem, you have:

project1/
project1/link1 -> ../../some/where/else

If you do a simple svn add link1 it adds a symlink entry to the subversion repository, but what you're trying to accomplish is getting the stuff under somewhere else into the tree.

If this is the case, then you're fighting in the wrong direction, you should make the real files and directories under link1, and make the target locations symlinks into the link1 directory. That would be a simple solution to the problem.

Another solution would be to make the location ../../some/where/else an svn location in it's own right, and make link1 an externals definition to that location. When you commit in the main directory, the externals would be committed at the same time which would achieve storing the information; however to ensure that the other location was kept in sync, you would have to make sure to update it to the same version as the stored data.

In my case, on my desktop, I have a settings directory:

$HOME/settings

This is a checked out copy of a directory containing .bashrc, .profile, .vimrc, .vim, etc. files and folders from an svn repo. All my profile files and directories were symlinks into this folder, so for example .profile -> settings/.profile, etc. When I make changes, they are reflected in the svn tree, which I can commit back to in order to ensure that I don't lose my config settings when I go to another system.

If you really want svn to follow symlinks as hardlinks (You can't make directory hardlinks because it would be a bad thing™), then you'll have to hack the svn client source so that it did what you wanted; but this would be a maintenance nightmare.

You could get away with making the symlink into a bind mount point directed at the target, but that has it's own issues - you would need to be root to accomplish this, and it ends up leaving funny entries in your /proc/mounts to accomplish this:

mount --bind /absolute/path/to/some/where/else project1/link1
</blockquote>

==Keeping recipes separate==
Computational recipes written in Python and imported by the SConstruct file of a workflow are normally stored in RSFSRC/book/Recipes.  The install process copies these recipes to a directory like $RSFROOT/lib/python2.5/site-packages/rsf/recipes and adds this directory to your PYTHONPATH so that Python can find them.

However, you can put you own recipes anywhere you want.  You only have to add that place to your PYTHONPATH like this (bash):
<syntaxhighlight lang="bash">
export PYTHONPATH=${PYTHONPATH}:path_to_my_recipes
</syntaxhighlight>
Or like this (csh):
<syntaxhighlight lang="bash">
setenv PYTHONPATH ${PYTHONPATH}:path_to_my_recipes
</syntaxhighlight>

==Keeping examples separate==
Madagascar's public collection of example workflows are stored in RSFSRC/book, but you can put your private workflows anywhere you want.  No special instructions are required.

However, Madagascar assumes that the workflows are organized into a three-level book/chapter/section directory hierarchy when it creates a directory tree for the data and locked figures associated with your workflow. It is not required, but it might be easier to find the data and locked figures if you put your workflows in a three-level directory tree something like this: path_to_my_book/chapter/section/SConstruct.

==Keeping data separate==
The location of the data portion of your *.rsf files is controlled by your DATAPATH environment variable.  However, you may want to keep the data for your private workflows in a different place, or several different places, than the data created by the public examples in RSFSRC/book.  The way to do that is to temporarily change the DATAPATH variable in the SConstruct ''before'' importing rsf.proj like this:
<syntaxhighlight lang="python">
import os
os.environ['DATAPATH'] = 'path_to_my_private_data'

from rsf.proj import *
</syntaxhighlight>

==Keeping locked figures separate==
The command "scons lock" in the directory of a workflow will store a "locked" copy of your figures for regression testing.  Normally these figures are stored in the location pointed to by your RSFFIGS variable, and that is where the figures from the figures repository should be stored for testing in RSFSRC/book.

However, you may want to keep your private figures in a different place.  The way to do that is to temporarily change the RSFFIGS variable in the SConstruct ''before'' importing rsf.proj like this:
<syntaxhighlight lang="python">
import os
os.environ['RSFFIGS'] = 'path_to_my_private_figures'

from rsf.proj import *
</syntaxhighlight>
If you also create a RSFALTFIGS environment variable pointing to path_to_my_private_figures, then the testing script sffiglist will automatically test your figures against those in RSFALTFIGS when the sffiglist command is executed from a location outside of RSFSRC/book.