-
Notifications
You must be signed in to change notification settings - Fork 145
WIP: hack to make nipy compile on linux with mkl #293
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Oh dear - yes - this is terribly ugly. Is there a way to make this change once? @alexis-roche - any comments here. Satra - did you submit some pull request or issue to numpy? |
My only comment is that we should now seriously think of cutting the lapack-dependent branch from nipy as I believe it's mainly experimental stuff. I would suggest to create a nipy-labs project to host that stuff. I could start doing that in a couple of weeks. |
That would be excellent. I wonder if there is time to get that done before the paper deadline, so we can release? |
I started here: Also I created a new project called It looks quite trivial. You might want to clean up setup files for ugly lapack-related installation fixes. Also, I am not sure what to do with the docs since I don't use sphinx. |
@matthew-brett - i didn't have time to track down the core issues - the info is the same on linux or osx, but it compiles fine without this hack on osx but not on linux. i'll see if i can get to it over this weekend. in either case though, i don't think that particular library should be exposed by numpy. i'll post an issue on numpy as well once i have a better understanding. |
Alexis - where are we on this one? |
Alexis - can I close this one? |
Sorry for being so slow to respond. Yes, I think we can close this one although we probably agree that it's a short term fix. I am not sure anymore what we have (or have not) decided re the Lapack dependence in the long run - maybe worthwhile clarifying again. |
@mwaskom - see this thread - this hack works, but i believe alexis had a better solution - i'm sorry i've lost track of this. but this issue is biting anyone with anaconda+accelerate on any platform currently. it can be tracked to how numpy returns site info. there is also a current scikit-learn thread on how to compile projects dependent on scipy/numpy without resorting to compiling with libraries and instead to directly use the function pointers from scipy/numpy (not completely applicable here, but mentioning it). |
Thanks Satra, So there's currently no way to install nipy in an environment with MKL numpy/scipy? That's...frustrating. |
to be specific, i think this is an issue with conda+accelerate - i don't know about canopy. however, if you compiled numpy/scipy with MKL yourself, you would have access to the libraries and this shouldn't be an issue. |
@alexis - where are we with this one? |
I don't think that's the right Alexis :) |
Oops |
* upstream/master: (115 commits) RF: make .travis.yml use travis Python and wheels RF: allow for run-to-run difference in SVD results BF: object deletion for Windows file delete errors BF: set matplotlib backend for realign command BF: deal with random signs for PCA on Windows BF: make use of dot compatible with numpy < 1.5 RF: decorator to insist on matplotlib agg backend BF: prepare use of print for Python 3 BF: agg mpl backend for tests writing png files TST: Save the result in the temp directory in which this runs. Simplify BF: Slowly understanding argparse. BF: Output file handling. BF: Resolve error handling logic. DOC: Define the output of aff2rot_zooms. ENH: support case n_cuts=1 ENH: removed useless line returns ENH: removed useless line returns ENH: reverted changes to nipy/COMMIT_INFO.txt ENH: removed empty line in list comprehension ...
Any progress here? |
@alexis-roche - any thoughts? We might be suffering from the fact that none of Alexis Bertrand or I use conda. |
Hi, As far as I understand, it was a blas/lapack-linking issue, which should now be fixed with the current master version that builds a lapack-lite distribution from C sources rather than trying to link with the system blas/lapack... https://github.com/nipy/nipy/blob/master/nipy/labs/setup.py At some point, we need to switch to the scipy mechanism that allows to get C pointers to lapack functions... does that work on conda? |
@alexis-roche - the issue is with as you said one is to use the c pointers to the lapack funcs. this works across platforms and distributions and would be the ideal solution. |
@satra - Right, but the result of https://github.com/nipy/nipy/blob/master/nipy/labs/setup.py Am I missing something? Anyway, this is all confusing... Sounds like we should proceed soon with the new approach. |
just tried compiling current master - and that library info comes from the get_info function:
|
OK, that's weird. Well, it probably comes line 79 in the above mentioned setup.py file where we provide the lapack_info even though it's not needed if |
Michael, Satra - have y'all got a desktop that could run as a buildbot and that compiles using conda, so we can continue to test this? |
* master: hrf_model was declared but never used do not execute non-executable, provide shebang for executable script minor typos Update design_matrix.py
@satra - OK to close this one? |
This is a WIP to allow nipy to be compiled under anaconda on linux with mkl support. unfortunately
numpy.get_info()
returns libraries that are not allowed to be distributed with mkl (mkl_lapack95_lp64).This ideally should be fixed in numpy, but this hack allows nipy to compile.