fail to import ROOT in python
Closed this issue · 27 comments
I recently install anaconda with python 3.6. Then I install root. Yet I could not import root in python.
Do other libraries work with conda? So can you make sure that if you install a library that is not yet on your system will be install correctly with conda and can be imported?
It could be that you did not prepend the conda path to the python path.
I have the same problem python 2.7
Python 2.7.13 |Anaconda 4.4.0 (64-bit)| (default, Dec 20 2016, 23:09:15)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out: http://continuum.io/thanks and https://anaconda.org
>>> import ROOT
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named ROOT
>>>
mikkel-ThinkPad-X1-Carbon-3rd@~/apps$conda list root
# packages in environment at /home/mikkel/apps/anaconda2:
#
root 5.34.32 py2.7_gcc4.8.2 nlesc
root-numpy 4.4.0 root5.34.32_py2.7 nlesc
rootpy master py2.7 nlesc
I guess it is worth mentioning that running root from terminal works i.e.
mikkel-ThinkPad-X1-Carbon-3rd@~/apps$root
Couldn't find font "-adobe-helvetica-medium-r-*-*-10-*-*-*-*-*-iso8859-1",
trying "fixed". Please fix your system so helvetica can be found,
this font typically is in the rpm (or pkg equivalent) package
XFree86-[75,100]dpi-fonts or fonts-xorg-[75,100]dpi.
*******************************************
* *
* W E L C O M E to R O O T *
* *
* Version 5.34/32 23 June 2015 *
* *
* You are welcome to visit our Web site *
* http://root.cern.ch *
* *
*******************************************
ROOT 5.34/32 (heads/v5-34-00-patches@v5-34-30-102-g626b950, Aug 12 2016, 10:30:00 on linuxx8664gcc)
CINT/ROOT C/C++ Interpreter version 5.18.00, July 2, 2010
Type ? for help. Commands must be C++ statements.
Enclose multiple statements between { }.
root [0] .q
fixed by source /path/to/anaconda2/bin/thisroot.sh
I have the same problem with python2.7.
export PYTHONPATH=/path/to/anaconda2/lib:$PYTHONPATH helps but I wouldn't call it a fix, neither what @lepmik does.
Hi @mayou36, @lepmik
I am using bash.
bin/thisroot.sh has to be executed from within a certain directory and anaconda does not seem to care about this
The necessity to run bin/thisroot.sh or exporting PYTHONPATH explicitly is what I believe an issue with the package. Anaconda is supposed to provide a self-sufficient environment through symlinks / paths hardcoding / including rpaths without help from the user. If we have to modify the environment ourselves, the package's recipes are incomplete and this is a bug of the package, which should be addressed.
Do other libraries work with conda?
Other packages are working just fine.
source activate your_environment
I am using the "root"/default environment, so there is nothing to switch to in my case.
This is true @bugaev, but mostly due to the fact that conda has changed the name, meaning, and behavior of the few environment variables that are available during environment activation. The packages just haven't been updated to reflect that.
@remenska: I just hope that the issue will not be closed by the developers because they saw in this thread that somebody found temporary workarounds.
Just now noticed your comment about installing it in the root anaconda environment. Would not recommend that, env variables are set on activation of the environment.
In any case, someone should check the latest docs on environment variables and just submit a small patch.
@bugaev, could you try installing in a different environment to see if it works there for you? E.g.:
conda create -n root6_py27 root=6 python=2.7
source activate root6_py27
As @remenska said, in the root conda environment, activation scripts do not get called. You could call this a bug (though I would say it's a conda bug), but in fact a solution is already given: install ROOT in a non-root conda environment and the script is called automatically :)
In the case of running it from the root conda environment, a fix might be to install the ROOT package in a fixed location, as described here. I'm not sure whether this works so well, I personally never tried it, did you ever try this @remenska?
@Hugo-Leung did you solve your problem in the meantime?
I did solve my problem by source /path/to/anaconda3/bin/thisroot.sh.
Ah, I see now what you meant @remenska, indeed in activateROOT.sh, the path variable in the source line should be changed to $CONDA_ENV_PATH$CONDA_PREFIX to make sure it works across Conda versions.
Oh, you already provided a different fix, so the only thing that needs to be done is rebuild the package and submit it to Anaconda?
@egpbos it's been a while now, but to be honest I think that fix didn't cut it either.
There are several possible scenarios and I'm not sure conda can handle them properly in combination with ROOT at the moment.
- This should properly work.
(root) $ conda create -n env root=x python=y
(root) $ source activate env
(env) $
- This used to work, haven't tried it lately.
(root) $ conda create -n env
(root) $ source activate env
(env) $ conda install root=x python=y
- I think this is a bad practice. If you use anaconda for other purposes, you will find many surprises (gcc may not work as expected anymore because it's an older version shipped for backwards compatibility on older linux flavours, python version may change to satisfy package requirements etc..)
(root) $ conda install root=x python=y
I'll see if I find the time this weekend to dig into it (can't make any promises), see what changed on the conda side, and what needs to change in the activation scripts. I have a feeling their meaning (post-link, pre-unlink, post-activate, post-reactivate) has also changed in the meantime.
Thank you @remenska and @egpbos
I tried remenska's No. 1 approach and it works.
The reason why I was (and still) reluctant to use environments is because I like using
#!/path/to/env python in my python scripts.
With python environments, I am forced to use shell wrappers to do source activate foo unless #!/path/to/anaconda/envs/foo/bin/python is enough.
Does anaconda guarantee that starting python executable from within environment 'foo' has the same effect as source activate foo? Perhaps, it is package-dependent and wouldn't work with nlesc root since remenska mentioned
env variables are set on activation of the environment
Calling a python executable from the environment directory directly wouldn't probably set env variables for the nlesc root package since no explicit source activate is involved, just like in case with the default anaconda environment.
In the case of running it from the root conda environment, a fix might be to install the ROOT package in a fixed location, as described here
I do have my own ROOT installation outside of anaconda. And I would love to use it since I compiled it with all the features I need. Anaconda installs its own root from nlesc channel as a dependency of rootpy. I wish it was possible to to instruct anaconda to use my local root installation for rootpy or instruct to compile root with custom flags. I guess I would have to write my own anaconda package for that.
With python environments, I am forced to use shell wrappers to do source activate foo unless #!/path/to/anaconda/envs/foo/bin/python is enough.
Does anaconda guarantee that starting python executable from within environment 'foo' has the same effect as source activate foo?
I don't have a conda environment at the moment, but you could check what happens to your environment variables after activation, if I remember correctly, all it does is prepend the /path/to/anaconda/env/bin to your PATH environment variable. Would it be considered too much fiddling in your python scripts to have that set? Again, problem is (unrelated to conda or anything, so even outside of it) that before using pyroot you always have to do source /path/to/anaconda2/bin/thisroot.sh right? That only sets another env variable as far as I remember, PYTHONPATH. So there you have it, setting two environment variables, while avoiding shell wrappers to do source activate env.
Wouldn't call it a fix either, but ROOT is also complicated and requires thisroot.sh to work with python.
I do have my own ROOT installation outside of anaconda. And I would love to use it since I compiled it with all the features I need. Anaconda installs its own root from nlesc channel as a dependency of rootpy. I wish it was possible to to instruct anaconda to use my local root installation for rootpy or instruct to compile root with custom flags. I guess I would have to write my own anaconda package for that.
You could always do that, and the only guarantee you have is that it will work on your own environment, linked against your own glibc and other system libs. What we tried to achieve is portability and backwards compatibility with these packages. That is why linux headers, gcc ...and the whole shebang is shipped.
Oh, and probably sets something like CONDA_ENV_PATH upon environment activation, at least it used to.
Offtopic, but may I ask why you like to hard-code the path to one specific Python interpreter in your scripts' she-bang line @bugaev ?
Apparently, if a package like NLeSC/root relies on activation scripts like "thisroot.sh" that are called through explicit call to "activate", that cannot be achieved.
The real problem is that ROOT relies on having thisroot.sh sourced. @bugaev Do you bypass it when you use your ROOT installation outside of anaconda?
@remenska I first thought that thisroot.sh is needed in NLeSC/root package because the package sets LD_LIBRARY_PATH. Then I realized that the activation script unsets this path after thisroot.sh finishes. This suggests that NLeSC doesn't strip and utilizes rpaths in its root binaries and perfectly happy with scenarios where its root is used without python. What is left in the end after thisroot.sh is updated PYTHONPATH only. As a person who only uses anaconda and has no slightest understanding of its inner workings, I had a belief that anaconda leaves this environment variables purely for users and resolves paths by using some other mechanisms like file links.
My point is that the package developers seems to have solved all the problems peculiar to ROOT itself and didn't address the pythonic part (python path resolution) that seems (again seems) to be facilitated by the anaconda framework.
From the user point of view, I am totally fine with the package using PYTHONPATH though. And I really appreciate the efforts of all contributors to the NLeSC/root project!
@remenska I first thought that thisroot.sh is needed in NLeSC/root package because the package sets LD_LIBRARY_PATH. Then I realized that the activation script unsets this path after thisroot.sh finishes. This suggests that NLeSC doesn't strip and utilizes rpaths in its root binaries and perfectly happy with scenarios where its root is used without python. What is left in the end after thisroot.sh is updated PYTHONPATH only. As a person who only uses anaconda and has no slightest understanding of its inner workings, I had a belief that anaconda leaves this environment variables purely for users and resolves paths by using some other mechanisms like file links.
Yes, the conda packaging system doesn't need any (and discourages) setting LD_LIBRARY_PATH, PYTHONPATH etc. In practise, any purely-python packages should work out of the box just by pointing to the right conda python binary in shebang, if you want to bypass activating an environment. Conda does indeed do a binary replace of rpath but only during building/packaging.
ROOT is stubborn and insists on having ROOTSYS (and PYTHONPATH for pyroot if I remember correctly) to work properly. Packaging can only solve so many things :)
If you have any suggestions around this, please feel free to submit a patch, for me it's been long enough that I have forgotten all the peculiarities. :)
Thanks again!
Oh, by the way: another perk of having ROOT installed in your root Anaconda environment instead of a custom one: even if installing it managed to activate thisroot.sh properly and set ROOTSYS for you behind the scenes, the next time you want to use some other custom-built ROOT and source that thisroot.sh, it will forever overwrite the existing ROOTSYS setting, so badly needed by ROOT. Since you don't need to activate anything with your root Anaconda, no other way but to manually set it back or source again (no advantage over conda activate)
That is one of the more obvious reasons why I discourage using that kind of setup.