Bug#729924: vim: Add Python 3 support

[James McCoy]

On Mon, Feb 03, 2014 at 05:38:12PM -0500, Barry Warsaw wrote:
> On Jan 31, 2014, at 11:04 PM, James McCoy wrote:
> 
> >First, the way Debian builds Python prevents loading both libpython2 and
> >libpython3 in the same process, since Debian's builds necessitate
> >passing RTLD_GLOBAL to dlopen().  This means that when Vim is built to
> >support both Python 2 & 3, one has to choose between using plugins that
> >target Python 2 or Python 3 instead of the user being able to use both.
> 
> I'd always envisioned that the end user would make a binary choice as to
> whether their plugins were Python 2 or 3, and then use one or the other in
> their vim process.  I don't know whether that's a reasonable assumption
> though.

The user doesn't necessarily have a choice in the matter.  If they find
plugins A and B that they want to use, but one is implemented in Python 2
and the other in Python 3, then they're either a) running Debian and out
of luck, b) running a distro that doesn't require RTLD_GLOBAL and
happy, or c) trying to convince one of the plugin authors to port their
plugin.

> I think we have other such precedence in Debian; I remember hacking on some
> package to dynamically load either Python 2 or Python 3 (but not both) support
> at runtime, but now I can't remember which package that is.  I personally
> don't think you'd need to support *both* Python 2 and Python 3 in the same
> process space, and I'm actually pretty skeptical that that would work!

I was part of some discussion[0] on the vim-dev list when this was being
fleshed out that shows it does work.  The problem is that Debian's
python builds don't link the C extensions against the relevant libpython.

> Does it change anything in your mind if vim plugins were limited to either
> Python 2 or Python 3, selectable at runtime by the end user?

That's essentially what already happens with dynamic loading enabled,
except the "user selection" is a matter of "run either :python or
:python3 before Python-using plugins are loaded to force the bindings
you want to be loaded."

From my maintainer perspective, the bigger issue is the lack of
traceability of dependencies to aid binNMUs and the like.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-vim-maintainers/attachments/20140203/b1bd8aea/attachment.sig>