Table of contents
- Caching dynamic content
- Domain mode
- Domains externally registered
- Email antispam
- Email client configuration
- Email out-of-office assistant
- Email sending with PHP
- Email sending with Wordpress
- Python Packages
- Python memory requirements
- SSH access
- SSH tunnel
- Secure downloads using X-Accel-Redirect
- Technical limitations
Confused?If there is anything unclear, please contact us. We are always glad to help.
All filesystems that are writeable by customers are mounted with the noexec flag. This means that virtualenv is not useable. The following text explains how to install your own packages regardless of this limitation.
See also Technical limitations
In order to install python packages you should first prepare the PYTHONPATH in which you want to install the packages:
$ mkdir -p $HOME/example.com/lib
Now create in Webconf > Python a new Application and add that newly created directory at the Site directories tab:
Path = /srv/home/webNNNN/example.com/lib
Afterwards you can activate the newly created application on the shell. Assuming you called the Application example:
$ pxenv example
Now you can install Python Packages with pip or easy_install. You just need to pass the target directory when using those commands:
$ pip install --target $HOME/example.com/lib (...) $ easy_install --install-dir $HOME/example.com/lib (...)
You can test the installation by starting an interactive python shell and trying to load the installed package. e.g.:
$ pip install --target $HOME/example.com/lib Django $ python >>> import django >>>
If you do not get to see an ImportError everything worked as expected and the package is now installed.
The noexec mounted filesystems also cause that you can not install packages which contain native code. Therefore we have preinstalled all database drivers, Pillow and many other packages on our systems. You can select them in Webconf on an application basis. If you need further packages please contact us.
Tip for your requirements.txt
As you can not install packages which contain native code it makes a lot of sense to split the requirements.txt into two parts:
requirements-live.txt - Only contains packages without native code
requirements.txt - Only contains packages with native code and includes the requirements-live.txt
- -r requirements-live.txt psycopg2>=2.6,<2.7 Pillow>=2.8,<2.9
That way you can install the requirements-live.txt on our Servers and use the requirements.txt for your local development environment.