28

On Linux systems, packaged Vim typically has only one of either python or python3 enabled. It is possible for both to be enabled (using python/dyn and python3/dyn), but during a session, only one can be used. This mailing list discussion said:

It depends on how the Python libraries are built. On Debian-based systems (for reasons I don't recall offhand), they're built such that RTLD_GLOBAL has to be used to get access to the symbols. This prevents loading both libpython2.x and libpython3.x in the same process.

What can be done to enable loading of both in the same session?

Options that I can see:

  • Rebuild the Python{2,3} packages so that RTLD_GLOBAL (whatever that may be) isn't needed.
  • Somehow get the library loaded earlier to be unloaded (?!) by Vim. (Is that even possible?)

For any particulars of the distro, assume, in increasing order of specificity:

  • Debian-based
  • Ubuntu
  • Ubuntu 14.04
  • Or, Arch Linux, if a Debian-based system is too complex.

Note that I have got Vim to build with dynamic loading support for both, so building Vim isn't a problem.

17

I'm the current Vim maintainer for Debian and the person quoted in the referenced mailing list discussion.

As you stated, this isn't a question about Vim. It's about building the software that Vim links against in a way that meets your needs. There's a more thorough discussion (at least for the Debian aspect) of the issue in a bug requesting Python3 to be enabled in Debian's Vim packaging.

This boils down to

  • Debian's Python packaging doesn't link the Python extensions against the relevant libpython shared library. This is what causes Debian's Vim packaging to require using RTLD_GLOBAL when using dlopen() to dynamically load the Python language bindings.

  • There aren't good ways to express the relationship between the Vim packages and the dynamically loaded libraries to ensure they're upgraded together when appropriate. Even if the first point were resolved, this issue would still prevent me from enabling dynamic loading of the Python support.

    The main point of dynamically loading the language support in Vim is to not require users to install libraries they won't use. This means the Vim packaging can't specify a hard dependency on a minimum version of a library.

    Therefore, if Vim is built against a newer version of a library that isn't backwards compatible with the older version and the user doesn't upgrade them together, Vim will crash. This isn't something I want the users of the packages to encounter.

I'd love to be able to re-enable (it was available for a short time back in 2010-2011) dynamic loading of language support, but the above issues have to be resolved first.


As of version 2:7.4.2330-1, Debian's packaging has switched to using Python3 instead of Python2 for the Python bindings.


As an alternative, the neovim package supports use of both Python2 and Python3 from the same nvim process, since the Python support is provided by external modules (the python-neovim and python3-neovim packages). Externalizing the Python code, rather than embedding it like Vim does, avoids the issue of dealing with how libpython is built.

  • "This means the Vim packaging can't specify a hard dependency on a minimum version of a library." I assume that's why Debian doesn't have separate packages for Vim+Python2 and Vim+Python3 the way Arch Linux has? – muru Feb 25 '15 at 22:49
  • @muru Python is only one of the language bindings available. Providing combinations of packages for the different languages and GUI toolkits is a large number of packages. The decision was to enable as many language bindings as was reasonable and let the choice be among GUI toolkits (or not). A user shouldn't have to choose Vim plugins based on the language they're written in. – jamessan Feb 26 '15 at 2:23
  • That is not a real argument, since only Python and Python3 conflict each other. I honestly think you should borrow a leaf from the Arch developers' book. Aside from a common vim-runtime package, they have vim, gvim, vim-python3 and gvim-python3. The only difference between the -python3 and the normal packages is the version of Python enabled. Sure, it doubles the number of frontend packages, but that's all the flaw I see in such packaging. – muru Feb 26 '15 at 2:55
  • That's for Arch. In Debian, there's vim-nox, vim-gtk, vim-gnome, and vim-athena. Doubling those just so that users still can't use both Python and Python3 plugins doesn't seem worthwhile. – jamessan Feb 26 '15 at 3:07
  • I'm mildly curious as to why you didn't pick the dynamic option for the normal packages. – muru Sep 14 '16 at 0:46
4

Ubuntu 16.04 now has vim-*-py2 packages included in the repo. This means all Debian Vim users can migrate to Ubuntu if needed.

The erstwhile vim-* packages now provide +python3, and the binaries are named differently to avoid conflict:

And so on.

  • So, on 16.04, I can load python2 and python3 in the same Vim session? – muru Mar 6 '16 at 19:15
  • @muru no, you can just pick which one you get in a given session more easily ;) – hobbs Apr 14 '16 at 5:32
  • @hobbs I'm pretty sure the packages conflict with the python3 ones. – muru Apr 14 '16 at 6:00
  • @muru they don't, in fact. You can have both installed and run whichever one you choose, as well as pick one to be your default vim. It's not great, but it's an improvement. – hobbs Apr 14 '16 at 6:18
  • 2
    And now with 17.04, Python 2 support and the relevant Vim packages have been dropped – muru Aug 29 '17 at 16:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.