Chris Friesen <chris.frie...@windriver.com> writes: > I'm pretty new to python, I'm trying to figure out how a python module > is supposed to make non-backwards-compatible changes without blowing > up the applications that use it.
The short answer is that Python doesn't have a library linker, so we do it through co-operative APIs and bundled third-party libraries, rather than versioned linking to shared libraries. > How would something like this work in a python application? I don't > see any way to do the equivalent of > > import foo version X You can have the library expose a ‘foo.version’ attribute (or, sometimes, a ‘foo.__version__’ attribute) and have the library user check for that. Ideally, make its value a tuple of integers (as Python does for its run-time version) so the library user can choose the level of precision it will match. Sadly, there's no way to have multiple versions of a library with the same name installed and available to the same application. You'll probably receive advice to install all your application's dependencies together in a so-called “virtualenv” with the application. This is dreadful practice – it ignores the OS package managed libraries, it requires every deployment to manage dependencies separately, it promotes needless duplication and potentially divergent code, it makes security updates a nightmare, etc. – but it appears to be the best Python has for this, given the lack of a versioned linking feature. -- \ “The trouble with the world is that the stupid are cocksure and | `\ the intelligent are full of doubt.” —Bertrand Russell | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
