install_ydk.sh tries to create a new venv

[valeriodigregorio]

Issue tracker is ONLY used for reporting bugs. Please use the YDK Community for any support issues.

Expected Behavior

install_ydk.sh should use currently sourced env/venv or alternatively allow the user to specify the venv location that has to be sourced.

Current Behavior

install_ydk.sh doesn't use currently sourced env/venv but rather tries to create a env unless venv folder is present in YDKGEN_HOME folder.

if [[ ! -d ${YDKGEN_HOME}/venv ]]; then
  print_msg "Creating Python3 virtual environment in ${YDKGEN_HOME}/venv"
  run_cmd python3 -m venv ${HOME}/venv
fi
run_cmd source ${HOME}/venv/bin/activate

Steps to Reproduce

1. create a venv in /myfolder/myvenv/
2. source /myfolder/myvenv/bin/activate
3. run install_ydk.sh
4. verify that YDK has not been installed in /myfolder/myvenv/

Your Script

N/A

Logs

N/A

System Information

Python 3.6.10, RHEL8.2, 16x Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz

[ygorelik]

This issue has been resolved previously under my fork. The script there has new capabilities including definition of environment variable PYTHON_VENV, which can set previously built python virtual environment.

[valeriodigregorio]

I can see in your fork you create a venv in $HOME/venv if PYTHON_VENV isn't set. I think we should not create a venv unless requested by the user. Reason is that installing this on a container doesn't really require a venv and anyways the user may want to install YDK in the real environment for many reasons.

[ygorelik]

The abandoning of idea to use virtual environment creates multidimensional Python environment building issues. We've seen them in multiple YDK installations across the globe. That is why in release 0.8.5 the usage of virtual environment was offered in the first place. And that is why installation script became possible to develop.

If for any reason you don't want to use virtual environment, you can install all YDK components manually.