Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
|Failed to load latest commit information.|
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 ...