install.sh shouldn't mess with the system site-package

[yukiisbored]

The user should be encourage to use a virtualenv or have install.sh set it up. Messing with the system site-package can cause damage with the system since it's usually handled by the operating system's package manager.

At some cases, the Python packages installed on the system can conflict with the ones being installed from pip.

This is why some Linux distributions/*BSDs patch pip to give the user a warning when pip is being run as root or a notice after the user installs pip.

[hongquan]

The device (Rasp Pi) is supposed to contain only our application (SUSI.AI), not other applications (like in server), so the risk of conflict is not high, and the complexity of carrying a virtualenv doesn't worth (has to decide how the name should be, where is the location).

We try to make our app work on the latest OS, latest Python, and try to always use the latest Python packages. Our application owns the device, not share the device with anything else, it can decide which version of software it wants, cannot be dragged by other applications (like in server environment). When most of the things are "latest", the compatibility issue will be less.

The pip on Debian (the most popular OS on embedded computer, from Raspberry Pi, to BeagleBone Black, to other Chinese-made board) doesn't complaint you about conflict possibility if running pip under root. It only gives warning about failure to access pip cache, due to permission difference. On Debian, if some Python packages are installed by apt, they will go to /usr/lib/, while if installed by sudo pip, they will go to /usr/local/lib, not overwrite system files.

So, at the end, I object using virtualenv for this project when deploy to devices.

But this can be changed after I finish finding an appropriate folder structure and deployment method for this project. If the deployment method is apt, the Python dependencies packages will be get from OS repository (absolutely no conflict), but if the deployment is snap or alike, there maybe way to include our collection of dependencies, isolated from the OS (it is like virtualenv, but we don't actually use virtualenv).