You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's no good resource (that I've found) that explains which CMSSW versions have which python and ROOT versions. They almost always come with some version of python 2.7 and python 3.x but ROOT (up until v6.22) can only be compiled for one version of python at a time - and in CMSSW it's almost always python 2.7.
This is dumb. We are 8 months past EOL of python 2.7 (1/1/2020). The trick to get a python3 version of ROOT (on LPC at least) is to just source the version of root you want after your cmsenv.
The problem is that v6.22 is built for python 3.8 compatibility and not 3.6 (it also has python2.7 support - having both is new to v6.22). So we also need to be in a CMSSW with python 3.8. I just grabbed the latest possible CMSSW to find this (without getting into the _pre versions). Here's the full setup.
cmsrel CMSSW_11_4_1 # has python 3.8 (root version we grab will be compiled for python3.8 but not python3.6)
cd CMSSW_11_4_1/src
cmsenv
source /cvmfs/cms.cern.ch/slc7_amd64_gcc820/lcg/root/6.22.00/bin/thisroot.sh # compiled for python2.7 and python3.8 (not for python3.6 which is why we need CMSSW_11_4_1)
python3 -c "import ROOT" # test python3 - should return nothing
python2.7 -c "import ROOT" # test python2.7 - should return nothing
Of course, this means that you need to source your root version manually after cmsenv. My recommendation around this is to do one of two things:
Setup an alias in your .bashrc like alias cmsenv_py3='cmsenv; source /cvmfs/cms.cern.ch/slc7_amd64_gcc820/lcg/root/6.22.00/bin/thisroot.sh'. Then use this alias instead of cmsenv.
Setup a python virtualenv and modify the activate script to run source /cvmfs/cms.cern.ch/slc7_amd64_gcc820/lcg/root/6.22.00/bin/thisroot.sh at the end.
With this option, you'll need to remember to activate the virtualenv every time after you cmsenv but in general, virtualenvs are good to use so you can install other python packages via pip.
(a) If you wanna be really cool, also modify the deactivate function in pyroot3/bin/activate so that it resets the root version to the original for CMSSW_11_4_1. I'm not gonna write it out because you could easily also run cmsenv to reset it.
Combine (1) and (2) so that the alias also does the virtualenv activating.
The text was updated successfully, but these errors were encountered:
There's no good resource (that I've found) that explains which CMSSW versions have which python and ROOT versions. They almost always come with some version of python 2.7 and python 3.x but ROOT (up until v6.22) can only be compiled for one version of python at a time - and in CMSSW it's almost always python 2.7.
This is dumb. We are 8 months past EOL of python 2.7 (1/1/2020). The trick to get a python3 version of ROOT (on LPC at least) is to just source the version of root you want after your
cmsenv
.source /cvmfs/cms.cern.ch/slc7_amd64_gcc820/lcg/root/6.22.00/bin/thisroot.sh
The problem is that v6.22 is built for python 3.8 compatibility and not 3.6 (it also has python2.7 support - having both is new to v6.22). So we also need to be in a CMSSW with python 3.8. I just grabbed the latest possible CMSSW to find this (without getting into the
_pre
versions). Here's the full setup.Of course, this means that you need to source your root version manually after cmsenv. My recommendation around this is to do one of two things:
.bashrc
likealias cmsenv_py3='cmsenv; source /cvmfs/cms.cern.ch/slc7_amd64_gcc820/lcg/root/6.22.00/bin/thisroot.sh'
. Then use this alias instead ofcmsenv
.source /cvmfs/cms.cern.ch/slc7_amd64_gcc820/lcg/root/6.22.00/bin/thisroot.sh
at the end.With this option, you'll need to remember to activate the virtualenv every time after you cmsenv but in general, virtualenvs are good to use so you can install other python packages via pip.
(a) If you wanna be really cool, also modify the
deactivate
function inpyroot3/bin/activate
so that it resets the root version to the original forCMSSW_11_4_1
. I'm not gonna write it out because you could easily also runcmsenv
to reset it.Combine (1) and (2) so that the alias also does the virtualenv activating.
The text was updated successfully, but these errors were encountered: