(experimental) add Conda Recipe for OS X

[ahmadia]

Don't merge this yet, working on my box but needs testing (and porting to Linux).

You can test this by downloading/installing conda (via Anaconda or Miniconda), then installing elemental with something like the following:

conda install -c elemental -c conda-forge elemental

Then the python should have access to elemental, and the library will be installed into the conda environment.

@poulson - I registered the elemental account on Anaconda.org so you would own the namespace, I can set you up with permissions on it once you have an Anaconda.org account.

[poulson]

This should be very helpful, thanks!

I assume that it is conda.recipe/cmake_parmetis.patch that needs to be generalized (as it has some hardcoded paths)?

[ahmadia]

Yeah those patches shouldn't be needed at all but something is fishy with cmake build on conda OS X. Linux recipe should be straightforward. Nice thing is it takes about five minutes to get a working install depending on your Internet speed.

[ahmadia]

And that patch is on the build side, it's not needed in the conda package itself. May need to write a short line of sed to do the fix in a slightly better way.

[gidiko]

Very-very recently we are seeing success in exposing libskylark as a set of conda recipes

Our most critical dependency is libelemental and so we put together for our needs a working recipe for linux64 available here

We pinned libelemental to a somewhat recent hash (just for the moment to insulate ourselves from any API changes). Let us know how we could help.

[ahmadia]

Awesome, I will start from there (and noticed a few mistakes in my recipe).

[poulson]

This PR seems to have generated a significant portion of the traffic to the project. The Python Effect is real.

[poulson]

@ahmadia It seems this PR might have lost steam. I assume it is still not meant to be merged?

[pzwang]

Hey guys, we have received a nudge from DARPA to try to get elemental (and its dependent packages like SmallK) built as conda packages, and made available on Anaconda Cloud... Any updates on this PR? @gidiko does your recipe/this recipe have any particular gotchas that we should be aware of? Otherwise, should we try to push forward on getting this added to conda-forge?

[gidiko]

Hi guys... @pzwang our recipe for libelemental works fine for libskylark purposes on linux-x86_64 (have quickly checked with some recent ubuntu, debian, centos flavors) so I see no immediate gotchas there.
In fact we are very happy with the conda approach, also because by simply adding constructor on top of the freshly built artifacts we additionally got a single file installer, ready to easily share our dependency-heavy software. No mac around now to see how the recipe here (i.e. the mac one) works for our needs in particular (btw, this would also mean mac versions for our other recipe dependencies, we also had to put together - which again work nicely together for linux-x86_64, ... but no mac versions there yet).

It would be super to have all these packages in conda-forge, so let's also share pointers on best practices on let's say "minigotchas" ( ala "miniconda" :) ) like the following and move forward:

1. How to deal with hard-coding build options. For example one of our dependencies is boost, however needed to be built with the "using mpi;" option. We had to do this already for the sake of libskylark, but does conda have a recommended way to mark this in a "version-like" tagging of the resulting binaries? Or we just have more descriptive names for the packages? Have not checked recently how people tend to do this.
2. How to deal with API evolving software. OK, we can (again) hardwire a commit hash (like for libelemental) but maybe there is a nicer way to do it (perhaps related to the previous bullet).
3. How to deal with GPL-licensed dependencies, I mean if there is an issue e.g. with (dynamically) linking to them (i.e. also having their depending recipes for them up in conda-forge).

[poulson]

@gidiko For what it's worth, Elemental has no GPL'd dependencies, though there are several (mostly optional) LGPL'd dependencies. The closest to mandatory are my reimplementations/extensions of Tim Davis's Sparse LDL package to handle real and complex matrices for arbitrary datatypes. But this could eventually be replaced with a clean room implementation without the LGPL license if necessary.

[poulson]

Now that there is an official release (https://github.com/elemental/Elemental/releases/tag/v0.87.4) and there are two Ubuntu packages, perhaps it is time to revisit anaconda support.