rdkit: Do we still need it in omnia?

[jchodera]

Since our omnia version of rdkit is out of date (2015.09.01) compared to the official rdkit conda version, should we drop it? Or update our own version?

[kyleabeauchamp]

It looks like they eventually plan to make conda-forge their official conda package, so presumably it makes sense to deprecate ours. See discussion rdkit/conda-rdkit#13

[kyleabeauchamp]

FWIW, you should check out this blog post:

https://www.continuum.io/blog/developer-blog/anaconda-build-migration-conda-forge

I think that, between the lines, Continuum is semi-officially suggesting that conda-forge is very nearly a "standard" secondary repository for reasonably stable conda packages. For this reason, the Bioconda folks are making efforts to better integrate with conda-forge.

[jchodera]

Sounds exciting! There is also an rdkit user group meeting next month we will send some folks to. Has anyone heard anything about support for projects that depends on CUDA or OpenCL? Alternatively, I imagine we could migrate a number of omnia projects to conda forge if we had a way to pull in some openmm packages built with our current build framework as a dependency.

[kyleabeauchamp]

I'm still wrapping my head around their CUDA support.

1. They build on an CENTOS6 image, which AFAIK is recent enough to get CUDA working
2. They do build theano, but it's not clear to me if the build has CUDA working: https://github.com/conda-forge/theano-feedstock
3. They may be waiting on some legal questions about CUDA re-distribution etc: WIP: Add CUDA and cuDNN conda-forge/docker-images#21

[kyleabeauchamp]

Short answer: they are still working on it.

[jchodera]

Thanks! Given the momentum behind it, it's still worth looking at whether it makes sense to migrate the non CUDA packages, or if that is even possible given the dependency structure and lack of ability to specify multiple channels for dependencies. Someone noted that it is possible to declare pip dependencies in conda recipes. If this were true, some pure python packages might be pip-able instead.

[kyleabeauchamp]

Conda will definitely install pip dependencies for environments ( env.yaml) but I don't think it works for conda-build recipes.

See the example yaml at the bottom of this page:

https://github.com/conda/conda-env

[rmcgibbo]

I just submitted mdtraj to conda-forge at conda-forge/staged-recipes#1477, which is my first experience so far. If things go smoothly, it might make sense for other people to slowly migrate over packages that don't depend on cuda/openmm.

[kyleabeauchamp]

SGTM, I just signed up to watch that thread.

[jchodera]

Thanks, @rmcgibbo! Watching too. Please share your experiences.

[kyleabeauchamp]

FWIW, mdtraj packages seem OK: https://anaconda.org/conda-forge/mdtraj/files. The feedstock repo has been created: https://github.com/conda-forge/mdtraj-feedstock

[rmcgibbo]

My impression so far is that the system for adding a new feedstock was very slick. The documentation was nice and clear, the example repo had very good defaults and instructions, and there was lots of cool cloud automation (like the linter automatically commenting on the Github PR, etc).

Sent from my iPhone

On Sep 4, 2016, at 7:04 PM, Kyle Beauchamp [email protected] wrote:

FWIW, mdtraj packages seem OK: https://anaconda.org/conda-forge/mdtraj/files. The feedstock repo has been created: https://github.com/conda-forge/mdtraj-feedstock

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[jchodera]

Awesome! Thanks for the report!

Any insight into how this might work for a package that depended on openmm? Is there some way to include the current omnia channel for pulling in dependencies? Would we just be migrating packages over to conda-forge instead of omnia if we started to move them there?

Looking forward to giving this a try...

[rmcgibbo]

I strongly doubt that depending on a package in the omnia channel is possible. I think moving openmm and any of its dependents to conda-forge will require figuring out cuda/opencl on their platform.

I'm not sure about this, but I suspect we may be among the people with the most experience packaging cuda stuff with conda using centos6/docker/travis-ci. So perhaps there's something we can contribute there.

Sent from my iPhone

On Sep 4, 2016, at 8:15 PM, John Chodera [email protected] wrote:

Awesome! Thanks for the report!

Any insight into how this might work for a package that depended on openmm? Is there some way to include the current omnia channel for pulling in dependencies? Would we just be migrating packages over to conda-forge instead of omnia if we started to move them there?

Looking forward to giving this a try...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[rbharath]

@jchodera Could you hold off on removing the rdkit on Omnia for a bit? I want to see if I can upgrade deepchem to use the official conda rdkit version without bugs first. (I just posted PR #582 after verifying that the old keras and theano on Omnia could be safely removed).

[jchodera]

Sure---let us know what you find!