I compiled the development version of Vim with both Python 2 and Python 3 support. The output of vim --version has +python/dyn and +python3/dyn in it. I ran the configure file with
g
./configure --enable-pythoninterp --enable-python3interp --with-python-config-dir=/usr/lib64/python2.7/config --with-python3-config-dir=/usr/lib64/python3.3/config --with-x --with-features=huge
However when I run :python import sys; print(sys.version) I get
E448: Could not load library function _PyArg_Parse_SizeT
E263: Sorry, this command is disabled, the Python library could not be loaded.
Why would this be? I found out because of YouCompleteMe stating that it requires Vim compiled with 2.x support.
Thanks
I had a similar issue on my Debian box. If you're using a Debian-based system, you will not be able to load both Python libraries simultaneously. That's why when you set --enable-python-interp and --enable-python3-interp they always load with the /dyn suffix.
If your vim plugins don't need both versions, you should just pick one of the versions and stick with it. The links below provide more info.
Explained by Debian maintainer
Vim Python Support
P.S. - In case you tried this on Windows as well, loading either Python version will work, so the /dyn isn't an issue there.
Related
I am trying to install jedi-vim. I am doing this at work - so I have to use gVim in Windows. I have already read several other posts in this forum. This has somehow made me smarter but still does not solve my problem.
I did the following things:
installed Pathogen
cloned jedi vim from https://github.com/davidhalter/jedi-vim.git and copied it to the bundle/ folder in the vim-dir.
Now, when I open a *.py-file vim always tells me
jedi-vim requires vim compiled with +python
but ':version' tells me that it's compiled with +python/dyn and +python3/dyn.
So what is the problem?
Additional infos:
vim version: 7.4
When I use ctrl+space to autocomplete a python key word, it tells me:
Error detected while processing function jedi#completions: line 1: E492: Not an editor command: Python jedi_vim.completions()
Error detected while processing function jedi#completions: line 1: E492: Not an editor command: Python jedi_vim.completions()
Press ENTER or type command to continue
I'm not sure if your are still experiencing the same issue, but after looking around I found this blog post that solved the problem for me. Essentially, it's just about re-installing vim (don't delete any config files) and then reinstalling from the source at the vim mercurial repo with the right flags. There might be a shorter/simpler version of doing this, but after trying back and forth many solutions, this one was the only one that worked:
Compiling Vim with Python and Ruby support on Ubuntu
These are the steps:
Check if Vim is compiled with Python:
$ vim --version | ack '(python)'
Remove Vim version installed:
$ sudo apt-get remove vim-common vim-runtime
Install dependencies needed to compile Vim:
$ sudo apt-get build-dep vim
Clone Vim repository, compile it and install the new version:
$ hg clone https://vim.googlecode.com/hg/ vim
$ cd vim
$ ./configure --enable-pythoninterp
$ make
$ sudo make install
+python/dyn means that Python support isn't statically compiled it, it's loaded dynamically when needed at runtime.
This is described in the python-dynamic help section:
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".
(Don't worry about the 2.4 there; I just happened to find docs from a few years ago. Read the help in your own copy of vim—or, better, do what the last paragraph says.)
So, either you don't have Python, you have the wrong version of Python, it's not on your %PATH%, vim is searching for it incorrectly, or it's failing to load.
At that time the problem was another one. I mixed up the architectures for vim and python - I used vim64Bit, but pyhton for 32bit.
I repaired that already some time ago but the other day I had to restart my computer and do some microsoft-Updates.
Unfortunately my vim (7.4) was totally broken. I had to re-set my home-dir. Then at least my vimrc was accessible again, but still my jedi in vim does not work.
Python is available in vim but still jedi does not seem to load correctly.
When I type "len(" in the beginning of a .py-file, at the place where arguments should be explained there are some strange characters, similar to this:
==jedi=0, == (_object_*) ==jedi==
When I type "self.", it says "unknown function: pythoncomplete#Complete"
I think it's only a configuration-issue, because it worked before the reboot.
Jedi is installed systemwide (with pip). If I try to install it "again", pip says that jedi is already installed.
I would appreciate your help very much ;-)
My OS is CentOS 7.0. It's embedded python version is 2.7, and I want to update it to Python 3.4.
when input the
print sys.path
output is:
['', '/usr/lib/python2.7/site-packages/setuptools-5.8-py2.7.egg',
'/usr/lib64/python27.zip', '/usr/lib64/python2.7',
'/usr/lib64/python2.7/plat-linux2', '/usr/lib64/python2.7/lib-tk',
'/usr/lib64/python2.7/lib-old', '/usr/lib64/python2.7/lib-dynload',
'/usr/lib64/python2.7/site-packages',
'/usr/lib64/python2.7/site-packages/gtk-2.0',
'/usr/lib/python2.7/site-packages']
So, if I download the python 3.7, then ./configure , make , make install. Will it override all the python-related files ? Or if I use the
./configure --prefix=***(some path)
then is it safe to remove all the old python files or directory?
In a word, hope someone gives me instructions about how to update to python 3 on linux. Thanks a lot.
Python 2 and 3 can safely be installed together. They install most of their files in different locations. So if the prefix is /usr/local, you'll find the library files in /usr/local/lib/pythonX.Y/ where X.Y are the major and minor version numbers.
The only point of contention is generally is the file python itself, which is generally a symbolic link.
Currently it seems most operating systems still use Python 2 as the default, which means that python is a symbolic link to python2. This is also recommended in the Python documentation.
It is best to leave it like that for now. Some programs in your distributions may depend on this, and might not work with Python 3.
So install Python 3 (3.5.1 is the latest version at this time) using your favorite package manager or compiling it yourself. And then use it by starting python3 or by putting #!/usr/bin/env python3 as the first line in your Python 3 scripts and making them executable (chmod +x <file>).
Python 2.7 Files are most likely still used by the OS and are therefore not safe to remove!
You can just run python3 using the
python3 [option]
command where option can be what you want to execute or how. or if you leave it blank you enter the python3 console.
Upgradeing your python2.7 to python3 is therefore not possible you will have to install python3 manually.
I have Python 2.7 and Python 3.3 in my Debian. I rebuilt both using the arg --enable-shared.
After than I built VIM 7.4 using the args " --enable-pythoninterp --enable-python3interp --with-features=huge --with-python-config-dir=PathToConfig --with-python3-config-dir=PathToConfig"
when i give the comment vim --version, I could see the flags '+python/dyn and +python3/dyn'
However when I type the command ':python import sys', I get the error message:
E448: Could not load library function _PyArg_Parse_SizeT
E263: Sorry, this command is disabled, the Python library could not be loaded.
When I type the command ':python3 import sys', I get the error message:
E448: Could not load library function PySys_SetArgv
E263: Sorry, this command is disabled, the Python library could not be loaded.
all the vim plugins that needs python is not working due to this.
Please let me know how to fix this.
"Dynamic" Python loading is only available for use on Windows, unfortunately. I have looked into this as well, and it is not available on any other operating system.
The Vim docs: http://vimdoc.sourceforge.net/htmldoc/if_pyth.html#python-dynamic specify: "On MS-Windows the Python library can be loaded dynamically."
Basically the answer is: Nope, "dynamic" will not work on any Mac/*nix systems.
What I've done on my own system is to compile two versions of vim, one with Python2 and the other with Python3 links. Then in my .vimrc I include a version-check to use the right python exec for plugins, etc.
Case: Testing clang_complete with gVim 7.3
I installed MinGW, then followed the tutorial here to download and compile clang. It compiled for around an hour, then make install. Clang worked. I especially love the error annotation. It's amazing.
Now comes the case of clang_complete. I Installed it. I am using pathogen, so clang_complete fron github comes in bundle folder inside vimfiles.
I opened the vim editor and gave command :scriptnames. It shows clang_complete plugin. :version shows it has python entry, so vim was built with python support.
Also my test system has python installed.
but whenever I issue :save foo1.cpp , vim give this error,
Error detected while processing function 14_ClangCompleteInit..14_initClangCompletePython:
line2
clang_complete:No python support available
line 3
cannot use clang library.
simply puzzled.
*I have python installed on my system.
I Also tried using libclang library path for clang_complete as mentioned in another question on clang_complete here, but to no avail.*
Thank you.
Vim needs to be compiled with Python support, i.e. +python when doing :version. -python means it's not installed. Taken from clang_complete at Github:
You need Vim 7.3 or higher, compiled with python support and ideally,
with the conceal feature.
You said you had this enabled, but it doesn't look like it. Taken from clang_complete.vim.
This is the only place that error message is defined and triggers on !has('python'). In other words this doesn't seem to be a clang_complete issue, but rather that your install is missing or is having problems with Python support.
function! s:initClangCompletePython()
if !has('python')
echoe 'clang_complete: No python support available.'
echoe 'Cannot use clang library'
echoe 'Compile vim with python support to use libclang'
return 0
endif
[..]
Just came across this issue, invoking :version returns for features:
-python
+python3
So it seems this is caused by incompatible plugin that requires python (e.g. 2.x) but only python 3.x is available.
I'm configuring a new Developing Server that came with Windows 7 64bits.
It must have installed Trac with Subversion integration.
I install Subversion with VisualSVN 2.1.1, clients with TortoiseSVN 1.6.7 and AnkhSVN 2.1.7 for Visual Studio 2008 SP1 integration.
All works fine! my problem begun when going to Trac installation.
I install python 2.6 all fine.
Trac hasn't a x64 windows installer, so I installed it manually by compiling it with python console (C:\Python26\python.exe C:/TRAC/setup.py install).
After that, I can create TRAC projects normally, the Trac core is working fine. And so the problem begins, lets take a look at the Trac INSTALL file:
Requirements
To install Trac, the following software packages must be installed:
Python, version >= 2.3.
Subversion, version >= 1.0. (>= 1.1.xrecommended)
Subversion SWIG Python bindings (not PySVN).
PySQLite,version 1.x (for SQLite 2.x) or version 2.x (for SQLite 3.x)
Clearsilver, version >= 0.9.3 (0.9.14 recommended)
Python: OK
Subverion: OK
Subversion SWIG Python bindings (not PySVN):
Here I face the first issue, he asks me for 'cd' to the swig directory and run the 'configure' file, and the result is:
C:\swigwin-1.3.40> c:\python26\python.exe configure
File "configure", line 16
DUALCASE=1; export DUALCASE # for MKS sh
^
SyntaxError: invalid syntax
PySQLite, version 1.x (for SQLite 2.x) or version 2.x (for SQLite 3.x):
Don't need, as Python 2.6 comes with SQLLite
Clearsilver, version >= 0.9.3 (0.9.14 recommended):
Second issue, Clearsilver only has 32bit installer wich does not recognize python installation (as registry keys are in different places from 32 to 64 bits).
So I try to manually install it with python console. It returns me a error of the same kind as SWIG:
C:\clearsilver-0.10.5>C:\python26\python.exe ./configure
File "./configure", line 13
if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then
^
SyntaxError: invalid syntax
When I simulate a web server using the "TRACD" command, it runs fine when I disable svn support but when I try to open the web page it shows me a error regarding ClearSilver is not installed for generating the html content.
AND (for making me more happy) This TRAC will run over IIS7, I mustn't install Apache...
I'm nearly crazy with this issue... HELP!!!
Just export Register from [HKEY_LOCAL_MACHINE\SOFTWARE\Python] to [HKEY_CURRENT_USER\Software\Python].
It's happens because trac only see the [HKEY_CURRENT_USER\Software\Python] and you installed the python "For all users"
I would expect that Trac on Windows instructions should work on x64, even if they're 32-bit packages. Have you tried this and failed?
Subversion SWIG Python bindings:
configure is not meant to be run by Python; it's meant to be run with a POSIX sh, like Bash or ksh. However, if you read subversion/bindings/swig/INSTALL you'll find that the installation instructions for Windows do not use configure; instead, Visual Studio and gen-make.py are used.
Note that your bindings should match your installed Subversion.
Clearsilver:
Likewise, configure is meant for a sh, not Python. Clearsilver compilation instructions for Windows can be found in clearsilver/python/README.txt.
Looks like I'm not the only one trying to install Trac on Win 7 64-bit, only to see the install crash and burn.
One problem is the lack of installed registry entries for Python on Win x64, which I was able to find via a web search. The problem was identified months ago, but unfortunately no patch release has been made available.
I was almost ready to give up on Trac, but the information here has given me new hope. Thanks all!