How to install Sionna in a shared virtual environment?

General Discussion
#1

I want to install Sionna in a shared virtual environment. So I have done:

$ sudo mkdir /opt/sionna
$ sudo -i python3 -m venv --system-site-packages /opt/sionna
$ source /opt/sionna/bin/activate
$ pip install tensorflow[and-cuda]
$ pip install sionna

This succeeds but I see lots of path warnings like:

WARNING: The scripts ipython and ipython3 are installed in '/home/<myname>/.local/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.

I think various users will need to run the scripts, so having them in my home directory isn’t suitable.

Is there a better way to install the scripts?

#2

[DeepMind assisted]

When setting up a shared virtual environment for Sionna (or any Python package), and especially when dealing with system-wide installations, it’s important to manage package scripts and executables in a way that they are accessible to all intended users without clashing with user-specific directories like /home/<myname>/.local/bin. Here’s a refined approach to address your concerns:

  1. Create the Virtual Environment:
  • You’ve already created the virtual environment at /opt/sionna correctly. This is a good practice as /opt is a common location for third-party software installations.
  1. Activating the Virtual Environment:
  • Activation is done correctly with source /opt/sionna/bin/activate. Ensure all users who need to use this environment have the permissions to access /opt/sionna.
  1. Installing TensorFlow and Sionna:
  • The installation commands for TensorFlow and Sionna are correct. However, when installing TensorFlow with [and-cuda], ensure that the CUDA and cuDNN libraries are correctly installed and accessible system-wide, not just within the virtual environment.
  1. Managing Script Warnings:
  • The warnings you’re seeing are due to pip installing executable scripts to a user’s local bin directory, which might not be in the system’s PATH. This is often a fallback when it doesn’t have the permissions to install these in the environment’s bin directory.
  • To ensure that the scripts are installed in the virtual environment’s bin directory (and thus, accessible to all users of the virtual environment), you can use the --no-warn-script-location option with pip, although this just suppresses the warning and does not change the install location.
  • A more robust solution is to ensure that pip has the necessary permissions to install scripts in the virtual environment’s bin directory. This might involve adjusting the permissions of the /opt/sionna directory so that the user installing the packages (or a group of users) has write access to it.
  1. Permissions:
  • Ensure that all users who need access to the virtual environment have the necessary permissions. You might need to set the group ownership of /opt/sionna to a common group that all intended users are a part of, and set the appropriate permissions. For example, sudo chgrp -R [group_name] /opt/sionna and sudo chmod -R 775 /opt/sionna can set the group and permissions respectively.
  1. PATH Adjustments:
  • Users will need to have /opt/sionna/bin in their PATH to easily use the executables. This can be done by adding export PATH="/opt/sionna/bin:$PATH" to the users’ .bashrc or .profile files, depending on their shell configuration.
  1. Virtual Environment Usage:
  • Remind users to activate the virtual environment using source /opt/sionna/bin/activate before using Sionna or any other packages installed in this environment. This ensures that the correct Python interpreter and installed packages are used.

By following these steps, you should be able to set up a shared virtual environment for Sionna that addresses the path warnings and is accessible and usable by all intended users.

#4

Hi Tim, thanks very much for your very helpful instructions. I didn’t understand this fully:

I pip installed TensorFlow[and-cuda] within the virtual environment. Is that correct? Or does that conflict with your statement ‘ensure that the CUDA and cuDNN libraries are correctly installed and accessible system-wide, not just within the virtual environment’?