#!/usr/bin/env bash

# function to create a virtual environment in a directory separate from
# where it is called. Its name is predictable based on where the script
# is called
#
# . /edx/var/jenkins/jobvenvs/virtualenv_tools.sh
# create_virtualenv --python=python3.8 --clear
# . "$venvpath/bin/activate"
#
# Optional Environmental Variables:
# 
# JOBVENVDIR - where on the system to create the virtualenv
#            - e.g. /edx/var/jenkins/jobvenvs
#
# Reason for existence: shiningpanda, the jenkins plugin that manages our
# virtualenvironments for jenkins jobs, is no longer supported so we need
# to stop using it. The tricky part is shiningpanda uses virtualenvwrapper
# underneath the hood, so while we're moving jenkins jobs to python3.8
# and beyond withOUT shiningpanda, we want to be careful to not futz with
# virtualenvwrapper environmental variables (which are required for it to
# function). Therefore, we have this separate implementation of virtualenv
# management.
#
# Why not create virtual environments right in the jenkins workspace
# where the job is run? Because workspaces are so deep in the filesystem
# that the autogenerated shebang line created by virtualenv on things in
# the virtualenv's bin directory will often be too long for the OS to
# parse.

function create_virtualenv () {
    if [ -z "${JOBVENVDIR:-}" ]
    then
        echo "No JOBVENVDIR found. Using default value." >&2
        JOBVENVDIR="/edx/var/jenkins/jobvenvs"
    fi

    # create a unique hash for the job based location of where job is run
    venvname="$(pwd | md5sum | cut -d' ' -f1)"

    # create the virtualenv
    virtualenv "$@" "$JOBVENVDIR/$venvname"

    # This variable is created in global scope if function is sourced
    # so we can access it after running this function.
    venvpath="$JOBVENVDIR/$venvname"
}