python2.7 must be given explicitly; cannot find `gsl`, `gsldev`

[ozagordi]

Hi. I just realised that many users might need to create the partis environment explicitly choosing python2.7. I tried without and compilation failed.

Further, I encountered this error

g++ -o bcrham -Ofast -std=c++11 _build/bcrham.o -L_build -lham -lyaml-cpp -lgsl -lgslcblas
/usr/bin/ld: cannot find -lgsl
/usr/bin/ld: cannot find -lgslcblas

that I could solve with a export LIBRARY_PATH=conda_base_location/envs/partis/lib

HT @mihuber

[psathyrella]

Is this with docker or without? If without, what kind of system are you on? And this is 2.7 as opposed to python 3? partis certainly doesn't work with 3, but it's a little weird that this wouldn't have come up before.

As far as gsl, I guess that depends what sort of system you're on -- when it happened before it seemed like it was a platform-specific thing that was pretty uncommon. On the other hand, this looks conda-related this time through, so I'm going to loop in Erick since he just added the conda stuff and I hardly understand conda. @matsen

[ozagordi]

Without docker. Since my conda installation is python 3 based, by default a new environment is created with python 3 and partis dependencies installation fails in one of many possible ways (for me it was a missing library). So I had to specify

conda create -n partis python=2.7

and the installation of all dependencies worked. Nevertheless, building partis failed because GSL and GSLCBLAS libraries could not be found, so I had to manually set LIBRARY_PATH.

One more nice thing would be to provide an installation procedure, otherwise the user always has to run from the github clone directory. Even better, putting it as a bioconda package would increase the adoption of the tool.

[matsen]

Yes, this is a consequence of conda mucking around with paths.

@ozagordi can you make a concrete suggestion? Should we document that you might want to do such an export when building with conda?

[matsen]

Oops-- I didn't reload to see your message, @ozagordi , until I posted mine.

Regarding 2.7, note that this is how we do things in the Dockerfile which serves as the real documentation of the install process.

[psathyrella]

OK so sounds like I should

• add python=2.7 to the conda create in the manual
• add a note that adding the conda path to LIBRARY_PATH may be necessary (I'm somewhat leary of telling everyone to muck around with their LIBRARY_PATH unless we can tell this is a general problem)
• make it more clear that the Dockerfile is the reference procedure

And I like the idea of making it a bioconda package, I'll look into it. But I can't figure out what this means:

One more nice thing would be to provide an installation procedure, otherwise the user always has to run from the github clone directory.

[ozagordi]

• I think that would help, yes.
• That was my hack, the correct way to solve this might be to modify SConstruct.
• That would help, too.

Partis lacks a setup.py file that would allow the user to do pip install or python setup.py install it, ideally in the environment. So the user has two options:

• run it like path_to_clone_directory/bin/partis
• add path_to_clone_directory/bin to $PATH.

If you go for the bioconda package, you might have to address this as well.

[psathyrella]

ok I think this is all set, although I'm still reading about bioconda packages, and will try to add that. So clarifying from above, the switch to conda in the docker file meant that after R installation, compilation was broken. Which was fine as long as you compiled once before installing R, but as you found, not if you didn't, or if you needed to compile twice. Since R is anyway a steaming pile, and we only use it for simulation, the R installation has been removed from the default install, so you only install it if you want to run simulation.

I looked into setup.py, but I don't think it would add a whole lot -- if nothing else partis depends on a lot of yaml and csv files that I think would have to be enumerated. The install procedure doesn't modify your path automatically since I don't like polluting default paths with scientific-quality code. I've switched the manual to calling the main binary with just its basename to force the issue, as well as listing the options for either modifying your PATH or using the full path to the binary. In addition to the two you mention, I also have linking just the partis binary to e.g. ~/bin/, which at least minimizes the pollution.