Improved Conda install, dependencies

htm-community / htm.core

Actively developed Hierarchical Temporal Memory (HTM) community fork (continuation) of NuPIC. Implementation for C++ and Python

http://numenta.org

GNU Affero General Public License v3.0

149 stars 74 forks source link

Improved Conda install, dependencies #795

Open breznak opened 4 years ago

breznak commented 4 years ago

@dkeeney I've recently been toying with our conda python install. Turns out I could be able to get most of the deps through conda (eigen, cereal, pybind11,..)

But our CMake would still try to install them from source. Would it be difficult to add a check "if exists, don't install from source"?

I don't want to replace our cmake self-contained build. As it's really convenient and tested. Works for porting to any new env.
The Conda alternative would be useful for cloud/server envs where one does not have priviledges to install any new SW, but conda is typically available (conda is also a sw manager/installer)

dkeeney commented 4 years ago

Yes I was thinking about that. It will take some research to figure out how to 'test' before 'installing' using cmake.

Let me first finish setting up my Ubuntu 18.4 environment so I can make sure that still builds.

breznak commented 4 years ago

Something like cmake's find_package with conda env: https://stackoverflow.com/questions/55934253/make-cmakes-find-packageboost-find-headers-inside-conda-environment

This is not urgent, but would be great if you could look into. As I hope we'll figure parameter optimization for NAB (#792 ) and then I'll abuse some of the university clusters for heavy computing ;)

breznak commented 4 years ago

relevant snip

I also want to change our build to check to see if boost is installed locally before downloading and building boost. However, the downloading occurs at configure time and the find_package(Boost...) occurs at build time. So, to use the find_package before the download would be difficult. In addition, there are so many variations on how the boost package can be constructed that it might not work even if there is an existing Boost installation. So I decided it was probably not worth it. ~dkeeney

breznak commented 4 years ago

I'm wondering if I should work on this further. PROs: simpler dependency management (our goal is not to support the install infrastructure) CONs: dependant on conda -> limited platforms?. We(you) already have done the hard work and the cmake/setup dependencies works fine.