GammaLib

Building binary conda packages is not as simple as I’d hoped.
I’ll continue investigating / trying to make this work for Gammalib / ctools.

Another example: https://github.com/mjuric/lsst_packaging_conda

I’ve created conda packages for both ctools and gammalib, and they seem to work (at least in my quick tests). Could anyone with more ctools experience do some more complex tests?

So far I have only built packages for macOS 64 bit with Python-3.6 (though it’s trivial to do others, once it is tested). So you need an anaconda distribution with python 3.6. The easiest way to test is to run the following (again only on a mac!):

create a virtual environment to test in and switch to it:¶

 
> conda create -n ctoolstest python=3.6 anaconda  
> source activate ctoolstest

you can omit “anaconda” from the first line if you want to have a smaller env with only python + ctools for testing, otherwise you get the full anaconda dist with all scientific packages

install the packages¶

(the packages are so far are only in my “kosack” channel on anaconda.org, until they are tested and then I will add them to “cta-observatory”:

> conda install -c kosack ctools     
Fetching package metadata ...............
Solving package specifications: .

Package plan for installation in environment /Users/kosack/anaconda/envs/ctools:

The following NEW packages will be INSTALLED:

    cfitsio:    3.410-2       openastronomy
    ctools:     1.2.0-py36_2  kosack       
    gammalib:   1.2.0-py36_1  kosack       
    openssl:    1.0.2k-1                   
    pip:        9.0.1-py36_1               
    python:     3.6.0-0                    
    readline:   6.2-2                      
    setuptools: 27.2.0-py36_0              
    sqlite:     3.13.0-0                   
    tk:         8.5.18-0                   
    wheel:      0.29.0-py36_0              
    xz:         5.2.2-1                    
    zlib:       1.2.8-3                    

Proceed ([y]/n)? 

That should fetch ctools and gammalib (1.2.0), install them to the virtual environment.

Make sure you do not set paths for PYTHON_PATH or GAMMALIB, etc, since they are not needed and will interfere with the installation.

Now, you should have a full ctools/gammalib install with python bindings! no gammalib-init.sh is needed.

Try it:¶

> ctbin --help
> which ctbin
/Users/kosack/anaconda/envs/ctoolstest/bin/ctbin

> python
PYTHON> from gammalib import cta
PYTHON> help(cta)

one more comment: you may need the cfitsio package, since I require it in the definition. You can get it via: conda install -c OpenAstronomy cfitsio. Eventually that can be added to the same cta-observatory channel, so only one channel needs to be added.

A few issues:

• the user shouldn’t have to set $CTOOLS or $GAMMALIB variables, since it is installed in a common place, but so far the code expects them to be there. Setting them both to $CONDA_PREVIX works, but this should not be necessary (though it seems to be a fundamental problem of how gammalib/ctools expect to be installed). That means the user must manually still set some variables after installing the package (unlike any other package)

• even with CTOOLS set correctly, no help info is found (e.g. ctbin --help says “no help available”). Seems to be that the manpages don’t get included in the package. Is that where tools get their help info? or do they look for some other file?

I guess the point is that the setup scripts need to be run, typically:

export GAMMALIB=/usr/local/gamma
source $GAMMALIB/bin/gammalib-init.sh
export CTOOLS=/usr/local/gamma
source $CTOOLS/bin/ctools-init.sh

guess the point is that the setup scripts need to be run, typically:

Yes, we just need to think how to do it correctly, since there is no “gamma” directory anymore, and the files can move around. With the packages, the software is installed in either /path/to/anaconda/{lib,share,bin,include} (if installed in the base environment) or in $CONDA_PREFIX/{lib,share,bin,include} if it is in a virtual environment, where CONDA_PREFIX depends on the name of the environment the user gave. It’s the same as if you had an RPM that installs it in /usr/ Therefore the location depends on the virtual environment name.

No other packages require you to set environment variables to find their support data (and packages know nothing about conda internally), so there must be a nicer mechanism to do it without having the user type “export CTOOLS=$CONDA_PREFIX” every time they want to use it.

I know at least PATH, LD_LIBRARY_PATH, etc get updated automatically, but I’m not sure if there is some standard for finding out if support files are in /usr/share or /usr/local/share, etc.