Removed python and python modules from the external products build

[javarias]

This commit address the issue reported in ticket #16.

This pull request allow to install python in a virtual environment. The system building ACS requires virtualenv and python already installed. The list of python python modules sources was removed from the ExtProd installation script.

The list of external python modules dependencies is handled and installed by pip, check the commit https://github.com/javarias/ACS/commit/796e917606c8b9cf2cf2a486d8cb7686d554b905 for the list of dependencies installed.

[DirkHoffmann]

I am not sure I understand all the consequences correctly. Does it mean that a pure installation will not work, unless the user knows the exact list of python packages to install? IIUC, there may be cases where repository RPMs interfere with (newer) python modules installed by PIP or any other off-YUM/RPM method. Wouldn't it be better to solve that problem by defining dependencies on python modules ("version >= x.y.z), installed by any method, rather than python RPMs then?

[javarias]

The patch suggested in this pull request will maintain the PYTHON_ROOT directory under ALMASW_INSTDIR directory. The main difference is that the real installation of python will not be provided by ACS, but rather by the linux distribution itself. After saying that, the following would be the directory structure of the PYTHON_ROOT directory, after the patch applied:

> find $PYTHON_ROOT
/alma/ACS-2014.6/Python
/alma/ACS-2014.6/Python/lib
/alma/ACS-2014.6/Python/lib/python2.6
/alma/ACS-2014.6/Python/lib/python2.6/site-packages
/alma/ACS-2014.6/Python/lib/python2.6/compileall.py
/alma/ACS-2014.6/Python/lib/python
/alma/ACS-2014.6/Python/lib/python/site-packages
/alma/ACS-2014.6/Python/lib/python/compileall.py
/alma/ACS-2014.6/Python/omni
/alma/ACS-2014.6/Python/bin
/alma/ACS-2014.6/Python/bin/python

In the previous listing; /alma/ACS-2014.6/Python/bin/python is symbolic link to /usr/bin/python which is installed as part of the system and /alma/ACS-2014.6/Python/lib/python2.6/compileall.py was copied from /usr/lib64/python2.6/compileall.py which is also installed as part of the python RPM.

The reason to still using a "fake python root" is to provide a 'sandbox' where the user could install whatever package and version wants, this without modifying the python system installation. It is very unlikely that a newer version of a package, installed in the ACS's PYTHON_ROOT, and also installed as part of the system python would interfere, because, if the ACS environment variables are used, the ACS's PYTHON_ROOT packages will take precedence over what is installed on the system and usually the packages don't import recursively the package with the same name in the PYTHONPATH.

To make ACS work after this patch, it is required to have installed a minimal installation of python, which nowadays every linux distribution installs by default (unless you install a LFS). I am not totally sure that all the listed python packages in this pull request description, are really used by ACS. What I just did was a map between what ACS installed as external python modules and what CentOS 6 + EPEL provided via yum.

Nonetheless, I agree with @DirkHoffmann regarding how to the dependencies have to be listed for ACS after the patch. I will modify the pull request description.

[DirkHoffmann]

Maybe the use of virtualenv would be a cleaner solution for cohabitation of system/distribution provided software and ACS-required packages.

[javarias]

Indeed, to use virtualenv sounds like a much cleaner solution. I will try that and then I will comment this push request.

[javarias]

I changed how the python is installed. Now it uses virtualenv to create the python sandbox. I was able to build successfully ACS entirely using the python installed with virtualenv.