Using virtualenvs

When multiple instances and/or multiple versions of the same instance coexist on a machine in production, we recommend using virtualenv, i.e. independent virtual environments where each project can use different sets of Python versions and libraries.

To use virtualenv Genropy provides, within the deploybuilder , a convenient script to bring the projects already present in an environment into a virtual environment principal.

It is recommended to first create a folder to host the virtualenv in the main root and enter it:

mkdir virtualenvs
cd virtualenvs

At this point it is sufficient to launch the script:

gnr app deploybuilder -e testvenv -c -p sandbox,mybilling -b develop

  • with the -e attribute we create the env folder (testenv), which will host our first env

  • with the -c attribute we specify the script to also copy the Genropy repository

  • with the -p attribute we specify to copy the projects, separated by commas (“sandbox” and “mybilling”)

  • with the -b attribute we choose to use the develop branch for Genropy

The genropy folders will then be re-proposed in the destination folder and, within the same projects folder (generally genropy_projects), the two projects “sandbox” and “mybilling”.

The virtualnv will at this point have its own environment , not contained in .gnr, but in the etc/gnr folder inside the virtualenv .

Once the virtual environment has been activated with:

source bin/activate

it will be possible to proceed with the deploybuilder , in a similar way to the standard case. The script will also create its own gnrdaemon (in our case gnrdaemon_testvenv) and its own gnrsiterunner (gnrsiterunner_testvenv).

Hint

Note that in the event of a start/restart, these will be the processes to be restarted, making the instances totally independent of the main ones:

sudo service gnrsiterunner_testvenv stop / start / restart
sudo service gnrdaemon_testvenv stop / start / restart

Section author: Davide Paci