https://github.com/mitsuhiko/multiversion

A hack that allows you to use different versions of the same library in the same Python process without clashes
https://github.com/mitsuhiko/multiversion

Last synced: 2 months ago
JSON representation

A hack that allows you to use different versions of the same library in the same Python process without clashes

• Host: GitHub
• URL: https://github.com/mitsuhiko/multiversion
• Owner: mitsuhiko
• License: other
• Created: 2011-06-15T09:43:54.000Z (over 13 years ago)
• Default Branch: master
• Last Pushed: 2011-06-15T12:49:35.000Z (over 13 years ago)
• Last Synced: 2024-10-13T01:41:05.809Z (3 months ago)
• Language: Python
• Homepage:
• Size: 88.9 KB
• Stars: 89
• Watchers: 3
• Forks: 9
• Open Issues: 1
• Metadata Files:
  • Readme: README
  • License: LICENSE

Awesome Lists containing this project

README

        

  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

      ...