Bug 1026502 - vim-enhanced does not provide python module and has weird compile options
vim-enhanced does not provide python module and has weird compile options
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: vim (Show other bugs)
19
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Karsten Hopp
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-04 14:43 EST by laus
Modified: 2014-07-22 09:39 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-07-22 09:39:52 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description laus 2013-11-04 14:43:21 EST
Description of problem:

when installing vim-enhanced one might expect python support, as pointed out in the summary of the package.

however vim --version tells

$ vim --version | grep python
+cryptv          +linebreak       +python/dyn      +viminfo
+cscope          +lispindent      -python3         +vreplace

that this package was compiled with +python/dyn not simply +python.

the vim documentation :help python-dynamic says on this:

"On MS-Windows the Python library can be loaded dynamically.  The :version
output then includes +python/dyn.

This means that Vim will search for the Python DLL file only when needed.
When you don't use the Python interface you don't need it, thus you can use
Vim without this DLL file.

To use the Python interface the Python DLL must be in your search path.  In a
console window type "path" to see what directories are used.

The name of the DLL must match the Python version Vim was compiled with.
Currently the name is "python24.dll".  That is for Python 2.4.  To know for
sure edit "gvim.exe" and search for "python\d*.dll\c"."

If this documentation is not deprecated it is a bit puzzling why vim was compiled this way.

In any case installing vim-enhanced does not install the proper python module and "import python" fails. As far as i know there is no other package that provides this module in fedora.

I would request to compile vim with +python (when vim-enhanced is installed) or to add a package vim-python, that then delivers the module.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. install vim-enhanced
2. open a python session
3. import vim

Actual results:
fails

Expected results:
imports vim module

Additional info:
Comment 1 Nicolas Dietrich 2014-07-17 17:03:50 EDT
I second the request of enabling `+python3`, this is really required.

I need to compile vim manually due to this.
Comment 2 Karsten Hopp 2014-07-22 09:39:52 EDT
The current vim isn't linked with any python libs:
>ldd /usr/bin/vim | grep python
>

But it still loads the python library when required, the documentation about 
python-dynamic being used on Windows only is misleading. In fact it is even required when you'd like to have support for both python2 and python3. See :help python-2-and-3 to get this info:
'When Python 2 and Python 3 are both supported they must be loaded dynamically'

But the next section in the 'python-2-and-3' documentation is what prevents me from enabling both:
'When doing this on Linux/Unix systems and importing global symbols, this leads
to a crash when the second Python version is used.  So either global symbols
are loaded but only one Python version is activated, or no global symbols are
loaded. The latter makes Python's "import" fail on libraries that expect the
symbols to be provided by Vim.'



Using --enable-pythoninterp=yes doesn't make a difference in functionality, it just adds a dependency on the python libs which isn't always wanted when you don't use the python interface.

So no, I can't add --enable-python3interp=dynamic at the moment and using --enable-pythoninterp=yes doesn't make any real difference, :python import vim works in both cases.

Note You need to log in before you can comment on or make changes to this bug.