On Wed, Apr 22, 2015 at 12:58:54PM +0200, Matthias Klose wrote: > On 04/22/2015 02:30 AM, James McCoy wrote: > > On Wed, Apr 22, 2015 at 12:58:38AM +0200, Matthias Klose wrote: > >> - note that in Debian python extensions aren't usually linked with > >> -lpythonX.Y. This is done to not depend on multiple python versions > >> when building an extension for multiple python versions in a single > >> binary package, but also to not load the shared library. I don't see > >> a memory waste here. Of course, the shared library is loaded when > >> an application is started using an embedded python interpreter (vim). > > > > Note that this decision prevents a single Vim instance from being able > > to run both Python2 and Python3 code. For that reason alone, I'd rather > > have extensions linked with -lpythonX.Y. That would be one step toward > > me being able to enable dynamic loading of language bindings in Vim. > > sure, but can't you just have one vim extension linked with the interpreter > which is loaded by default? In general, applications embedding the python > interpreter should just support one language version, and that should be Python3 > at this time. Not sure I like the gdb way to build two versions of the debugger > for different python versions. Currently I don't dynamically load any of the language bindings because I don't think we (Debian) have good support for automatically managing application upgrades when a dynamically loaded library has a transition. Since the express purpose of dynamically loading is to avoid a hard dependency, simple binNMUs aren't sufficient. One would have to manually add relevant Breaks to any libraries that are being dynamically loaded so the libraries don't get upgraded without the application. If I'm wrong and someone can educate me otherwise, I'd be happy. However, with the current state of affairs, I've stuck with dynamic linking so binNMUs handle any transitions Vim is apart of instead of risking Vim crashing because it wasn't upgraded along with a supporting, dynamically loaded library. If I were dynamically loading the language bindings then, due to the way Python extensions are built in Debian, Vim will load whichever Python version a script uses first and block the other version from loading in that Vim session. This isn't very friendly to people that shouldn't have to care about what language some plugin author chose to use. Pulling the language binding out into its own module which is linked against libpython isn't currently supported in Vim. Also, due to the functionality exposed to the language bindings, I would have to build multiple versions of this hypothetical module to support both vim and gvim. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan@debian.org>
Attachment:
signature.asc
Description: Digital signature