Python - Distributing Library With Source

Question

I'm writing a program that uses some cryptography for a class. Since I'm low on time, I'd like to go with Python for this assignment. The issue that I run into is that the code must be able to work on the Linux machines at the school. We are able to SSH into those machines and run the code, but we aren't allowed to install anything. I'm using the Cryptography library for Python:

pip install cryptography

Is there a straightforward way that I can include this with my .py file such that the issue of not being able to install the library on the Linux machines won't be a problem?

Answer 1

You have few options:

virtualenv

Install into virtualenv (assuming command virtualenv is installed):

$ cd projectdir
$ virtualenv venv
$ source venv/bin/activate
(venv)$ pip install cryptography
(venv)$ vim mycode.py
(venv)$ python mycode.py

The trick is, you install into local virtual environment, which does not requires root priviledges.

tox

tox is great tool. After investing a bit of time, you can easily create multiple virtualenvs.

It assumes, you have tox installed in your system.

$ tox-quickstart
$ ...accept all defaults
$ vim tox.ini

The tox.ini my look like:

[tox]
envlist = py27
skipsdist = true

[testenv]
commands = python --version
deps =
    cryptography

then run (with virtualenvs being deactivated):

$ tox

it will create virtualenv in directory .tox/py27

Activate it (still being in the same dir):

$ source .tox/py27/bin/activate
(py27)$ pip freeze
cryptography==1.2.2
... and few more...

Install into --user python profile

While this allows installing without root priviledges, it is not recommended as it soon ends in one big mess.

EDIT (reaction to MattDMo comment):

If one user has two project with conflicting requirements (e.g. different package versions), --user installation will not work as the packages are living in one scope shared across all user projects.

With virtualenvs you may keep virtualenv inside of project folders and feel free to destroy and recreate or modify any of them without affecting any other project.

Virtualenvs have no problem with "piling up": if you can find your project folder, you shall be able to find and manage related virtualenv(s) in it.

Use of virtualenv became de-facto recommended standard. I remember numerous examples starting with creating virtualenv, but I cannot remember one case using $ pip install --user.