multiversion
````````````
What many (including myself) said could not be done is now working on
any conforming Python 2.x interpreter. How does it work? Have a look
at the example module.
// Implementation
The implementation works by rewriting import calls internally into an
version encoded name. That way we can still take advantage of the
internal Python module caching. The modules are found on the whole
PYTHONPATH by looking for ``modulename-version``. If such a folder
exists it will add a fake module and provide whatever module is stored
in there versioned.
The rewriting is clever enough to track imports inside a module to
itself and its submodules.
// Limitations
The boundary is the current file. So you can't have two different
versions of a library to be used by the same file. But you can
separate the code into two files, each of which depends on a different
version of a specific library.
// Why?
Because I needed something for my EuroPython talk that involves all
kinds of retarded hackery you really shouldn't be doing.
// Does it work?
Surprisingly well actually.
// Example usage
The following code will look for Jinja2 in a folder `jinja2-1.0`
somewhere on the PYTHONPATH. This folder will have to contain
another folder called `jinja2` which is the actual package to
be imported then. Instead of a package it can also be a regular
Python module.
import multiversion
multiversion.require_version('jinja2', '1.0')
from jinja2 import Template
...