.. _installation_guide/appendix/virtualenv:

Using virtualenvs
=================




When multiple instances and/or multiple versions of the same instance coexist on a machine in production, we recommend using `virtualenv <https://docs.python.org/3/library/venv.html>`_, i.e. independent virtual environments where each project can use different sets of Python versions and libraries.

To use *virtualenv* Genropy provides, within the  :ref:`deploybuilder<installation_guide/deploy/gnrdeploybuilder>` , 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  :ref:`environment<installation_guide/configuration/default_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  :ref:`deploybuilder<installation_guide/deploy/gnrdeploybuilder>` , 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

.. sectionauthor:: Davide Paci