Develop Reference

Installing jedi-vim fails: vim says wrongly that +python is not compiled

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 ;-)

Python installation, failing to find bz2 module

OK, I have an old Debian VM. Package managers are useless. No, I'm not going to update the OS.
I have the bzip2 lib and development headers installed correctly on my system (those actually came from a package).
I start with absolutely NO Python on the system. I removed everything manually. I downloaded the Python 2.7.5 source, and configured with ./configure --prefix=/usr. It configures fine. I run make, and it compiles fine. I try ./python -c "import bz2; print bz2.__doc__", it works, and says:
The python bz2 module provides a comprehensive interface for
the bz2 compression library. It implements a complete file
interface, one shot (de)compression functions, and types for
sequential (de)compression.
I then run make test and the whole test suite progresses fine, and notably the "test_bz2" test passes.
I then run make install, which installs my new Python binary into /usr/bin/ like I wanted.
I try /usr/bin/python -c "import bz2; print bz2.__doc__", and it fails with:
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named bz2
I've tried a bunch of different things, including building Python as --enable-shared and not, no luck. I've tried at least 10 times (each time totally cleaning out everything, running make distclean, etc.). No luck.
I tried: PYTHONPATH="/usr/lib/python2.7"; export PYTHONPATH. Still no luck.
HOWEVER, if I delete the symlink that make install creates for /usr/bin/python, and instead do: ln -s /path/to/my/python/compile/python python, NOW it magically works.
So, what the heck? Why is this Python binary I'm getting created only able to find stuff when the binary exists in the compile directory, and not when it's put into normal production install location? What am I missing?
I am root during the entire process, from configure to make to make install to trying to test the Python import call.
I have started from scratch again (this time compiling with --enable-shared btw), and verified that not only in the compile directory is there build/lib.linux-x86_64-2.7/bz2.so, but once I run make install, that file is put into /usr/lib/python2.7/lib-dynload/bz2.so.
I've tried to do some reading on lib-dynload, but haven't been able to determine if there's something else a Python program (like default configuration for the CLI or whatever) would need to be able to tell it to pull module imports from lib-dynload, or if there's some other place or option to tell the make install where it should be putting it instead of dynload.
Still I have no explanation why the /path/to/compilation/python binary can find and load bz2.so fine, but the /usr/bin/python binary can't find (or load) /usr/lib/python2.7/lib-dynload/bz2.so.
I thought maybe it was something to do with the fact that the installation doesn't create like a /usr/lib/python symlink to point at /usr/lib/python2.7 directory. But I created the symlink and still no go.
I am still lost here.

It would appear that a sort of non-answer answer was arrived at accidentally via a long string of Twitter conversation(s).
I've filed another Stack Overflow question here to ask WHY what we found was the solution to this problem: https://stackoverflow.com/questions/17662091/python-installation-prefix-not-being-persisted-in-config
For posterity sake, right now the solution is that I have to set the PYTHONHOME environment variable to /usr, and everything starts working. The puzzling part is that the documentation says PYTHONHOME should default to {prefix}, which I was clearly setting as default during configure to /usr. So why should I have to manually set it?
Running python-config --prefix reveals that the {prefix} default is in fact /usr/bin, NOT /usr like I specified, which leads to me needing to override the default back to the default, bizarrely.

Building Python and more on missing modules

I have another thread asking help on "missing zlib". With the nice help the problem has been resolved (almost).
Now I am interested in building Python myself (on Ubuntu 10.10).
A few important questions have caught my attention:
After building Python (say 2.7.1), do I need to rebuild Python if I have missing modules?
Is there a way to find out what modules will be missing prior to building Python? Say sqlite3. I have sqlite3 installed for the system default (Python 2.6.6), and I can import that into Python 2.6.6 shell. Now I use pythonbrew to build 2.7.1, and in the shell I cannot import sqlite3 because _sqlite3 is not available. I am sure there are a few more important one missing which I need for future development (such as Django..).
I am willing to learn how to build without using pythonbrew.
Please share with me your experience in building another version of Python, and how would you address the problem of missing modules? Is there a practical solution to building Python?
I have never bothered building one myself, so please bear with me. I am beginning to realize the importance of learning and building one myself! Thank you very much!
EDIT
First I thank you all of your inputs. They meant a lot. I did the building.
Python build finished, but the necessary bits to build these modules were not found:
_bsddb _curses _curses_panel
_tkinter bsddb185 bz2
dbm gdbm readline
sunaudiodev _sqlite3
To find the necessary bits, look in setup.py in detect_modules() for the module's name.
I got sqlite3 and readline away by
sudo apt-get install libreadline6 libreadline6-dev
sudo apt-get install libsqlite3-dev
I tried to import them, but still "no named module xxxx".
At AskUbuntu I actually asked people how to get previous commands because I couldn't use that feature when I am in Python 2.7.1 shell. I believe it's due to readline.
Readline
I installed the Python-2.7.1 under this directory: /home/jwxie518/python27/
I looked into setup.py, I found the following lines:
# The sqlite interface
sqlite_setup_debug = False # verbose debug prints from this script?
# We hunt for #define SQLITE_VERSION "n.n.n"
# We need to find >= sqlite version 3.0.8
sqlite_incdir = sqlite_libdir = None
sqlite_inc_paths = [ '/usr/include',
'/usr/include/sqlite',
'/usr/include/sqlite3',
'/usr/local/include',
'/usr/local/include/sqlite',
'/usr/local/include/sqlite3',
]
All the paths listed above do not exist.
So I guess I have to install sqlite3 manually? I got another reference here (it's in Chinese, however)
# Download the latest and extract
# Go into the extracted directory
./configure --prefix=/home/jwxie518/python27/python
make && make install
# Then edit python-2.7 's setup.py before rebuild it
# Sample (add these two lines to the end....)
'~/share/software/python/sqlite-3.6.20/include',
'~/share/software/python/sqlite-3.6.20/include/sqlite3',
# Then rebuild python like how we did before
I went into my directory where I installed sqlite3. I found include/sqlite3.h only. So I went back and check /usr/include/. I can only find sqlite3.h too.
So what is going on here? Readline is also non-importable.
3RD EDIT
I started everything over, except I didn't reinstall sqlite3.
# Extract Python-2.7.1
# cd into Python-2.7.1
# ./configure
make >make.out 2>&1
less make.out
make.out is here: http://pastebin.com/raw.php?i=7k3BfxZQ
I still couldn't import sqlite3. So I went into setup.py and made changes:
# We hunt for #define SQLITE_VERSION "n.n.n"
# We need to find >= sqlite version 3.0.8
sqlite_incdir = sqlite_libdir = None
sqlite_inc_paths = [ '/usr/include',
'/usr/include/sqlite',
'/usr/include/sqlite3',
'/usr/local/include',
'/usr/local/include/sqlite',
'/usr/local/include/sqlite3',
'/home/jwxie518/python-mod/include/sqlite',
'/home/jwxie518/python-mod/include/sqlite3',
]
Then again, ran everything over (this time I also did make clean)
Output is here: http://pastebin.com/raw.php?i=8ZKgAcWn
According to the output, I don't think the custom path is included.... (for complete output please go to the link above and search for sqlite)
build/temp.linux-i686-2.7/home/jwxie518/Python-2.7.1/Modules/_sqlite/util.o
-L/usr/lib -L/usr/local/lib -Wl,-R/usr/lib -lsqlite3 -o build/lib.linux-i686-2.7/_sqlite3.so
I still cannot import sqlite3.
THanks!
Thank you very much, Michael Dillon, for helping me out. Your tutorial was neat and clear.
I solved the problem as soon as I realized whenever I tried Python-2.7.1, I was actually using the one installed by Pythonbrew.
The moral of the story is read all the errors. I neglected the errors generated by importing sqlite3. The one installed by Pythonbrew didn't have sqlite3 installed. The development package for sqlite3 was installed after Pythonbrew installed the Python-2.7.1
Thanks.

Here is how to build Python and fix any dependencies. I am assuming that you want this Python to be entirely separate from the Ubuntu release Python, so I am specifying the --prefix option to install it all in /home/python27 using the standard Python layout, i.e. site-packages instead of dist-packages.
1. Get the .tar.gz file into your own home directory.
2. tar zxvf Py*.tar.gz
3. cd Py*1
4. ./configure --prefix=/home/python27
5. make
6. make install
Step 5 is the important one. At the end, it will display a list of any modules that could not be built properly. Often you can fix this by installing an Ubuntu package, and rerunning make.
a. sudo apt-get install something-dev
b. make
It is pretty common to have a problem because you are missing the -dev addon to some module or other. But sometimes you should start over like this:
a. make clean
b. ./configure --prefix=/home/python27
c. make
Starting over never hurts if you are unsure. An important note about step 6. I am not using sudo on this command which means that you will need to have the /home/python27 directory already created with the appropriate ownership.
Don't hesitate to try out ./configure --help |less before building something because there may be interesting options that you could use. One time on a minimal distro I had to do --with-dbmliborder=gdbm:bdb in order to get gdbm working. When you run ./configure, the last few lines will tell you where it put the information that it learned. In the case of Python, Modules/Setup has been useful to figure out how to get a module to build.
Another useful thing is to make clean and then run make >make.out 2>&1 to capture all the output from the full make process. Then, after it is complete, use less or an editor to look for the details on a problem module such as _sqlite. For instance, check all the -I options that are passed to gcc. If the correct include directory is not on the list that would cause a problem. You can edit setup.py to change the list of include directories.
In the past it was more common to have library problems that would be fixed by logging out, logging in again, and running "sudo ldconfig" before doing a complete rebuild.

py2app built app displays `ERROR: pygame.macosx import FAILED` on other machines

Trying to build an app on the Mac using py2app. Got everything working fine on my machine, but when moving the app to another, it crashes and the console displays this error.
ERROR: pygame.macosx import FAILED
Anybody have a solution to this?

Found the problem and solution after many hours. Turns out other people have experienced similar problems and their articles were quite helpful:
http://b.atcg.us/blog/2010/04/13/py2app-hell-the-first.html
http://www.vijayp.ca/blog/?p=62
In case someone else runs into the issue, this particular problem was caused because the Python framework was not being bundled into the application. You can confirm this by right-clicking your app to view package contents, then proceed to Contents/Frameworks/. If Python.framework is not there, it should be.
Be sure to download Python -
My first issue was reliance on Apple's build in Python package. Don't use this. You need to install your own version of python. Go to http://www.python.org/download/releases/, find a version (I stuck with 2.6), download the gzip (not the mac package), and install with the following if you are running Snow Leopard:
./configure --enable-framework MACOSX_DEPLOYMENT_TARGET=10.6 --with-universal-archs=intel --enable-universalsdk=/
make
sudo make install
Adjust Paths, Install Packages - From here there you need to adjust your paths to ensure you are using your custom-installed version. From here, I reinstalled the following packages - this turned out to be a dependency nightmare so I'm including the version numbers as well:
py2app 0.5.2
macholib 1.3
modulegraph .8.0
If these packages actually worked, you should be able to build and run your app now. Unfortunately, they don't. I'll go into the errors and my hacked solutions in a bit, but there's some settings in the build file that need to be made first.
First the setup.py file should like a little somethin' like this:
setup.py
from setuptools import setup
APP = ['Game.py']
DATA_FILES = ['data']
OPTIONS = {
"argv_emulation": False,
"compressed" : True,
"optimize":2,
"iconfile":'data/game.icns',
}
setup(
app=APP,
data_files=DATA_FILES,
options={'py2app': OPTIONS},
)
then to be extra safe, I use a shell script to call this.
build.sh
## Remove previous builds. Start with clean slate.
rm -rf build dist
## Force python into 32 bit mode.
export VERSIONER_PYTHON_PREFER_32_BIT=yes
## Force build with custom installed python
/Library/Frameworks/Python.framework/Versions/2.6/bin/python setup.py py2app
Running build.sh should compile the app. If it does not compile, I have good news -- it's not your fault. Due to glitches in the libraries, you may run into some (or all) of the following:
Potential Problems
If the build script fails, scan the traceback for some of the following keywords:
pygame not found - basic path problem in py2app. Add...
sys.path.insert(0, os.path.join(os.getcwd(), 'lib', 'python2.6','lib-dynload')) ## Added to fix dynlib bug
after the import statements in boot_app.py in the py2app lib.
pythonNone - This appears to be a bug in the macho package where it cannot determine the version number of your python build. To solve this, I added the following lines to build_app.py in py2app.
## Add these two lines...
if not info["version"]:
info["version"] = "2.6"
## Before this line. (line 941 in method copy_python_framework() at time of writing)
pydir = 'python%s'%(info['version'])
No such file or directory...Python.framework/[lib|include] - py2app is simply looking for directories that exist deeper in the file system tree. Go to the Python.framework directory and symlink up the place...
cd /Library/Frameworks/Python.framework
sudo ln -s Versions/Current/include/ include
sudo ln -s Versions/Current/lib lib
That should do it! - These steps created a compiled app that worked on other intel machines.

Thank you for posting what you found!
I had a similar problem. I tried various combinations of what you suggested, and isolated the single issue for me to be the bug in boot_app.py which you identify above.
Once I added the one-line fix to boot_app.py which you identify above, everything worked, even using the pre-installed Apple build of python (version 2.6.1).
I should note that when I say "everything worked," I really mean building a py2app app for actual distribution, i.e. using the normal command:
python setup.py py2app
The "alias" mode. i.e.
python setup.py py2app -A
which the py2app documentation suggests for use during development, still does not work for me (with the same module not found error). But better the actual distribution build working than nothing at all! Again, thanks.

How to install PySide v0.3.1 on Mac OS X?

I'm trying to install PySide v0.3.1 in Mac OS X, for Qt development in python.
As a pre-requisite, I have installed CMake and the Qt SDK.
I have gone through the documentation and come up with the following installation script:
export PYSIDE_BASE_DIR="<my_dir>"
export APIEXTRACTOR_DIR="$PYSIDE_BASE_DIR/apiextractor-0.5.1"
export GENERATORRUNNER_DIR="$PYSIDE_BASE_DIR/generatorrunner-0.4.2"
export SHIBOKEN_DIR="$PYSIDE_BASE_DIR/shiboken-0.3.1"
export PYSIDE_DIR="$PYSIDE_BASE_DIR/pyside-qt4.6+0.3.1"
export PYSIDE_TOOLS_DIR="$PYSIDE_BASE_DIR/pyside-tools-0.1.3"
pushd .
cd $APIEXTRACTOR_DIR
cmake .
cd $GENERATORRUNNER_DIR
cmake -DApiExtractor_DIR=$APIEXTRACTOR_DIR .
cd $SHIBOKEN_DIR
cmake -DApiExtractor_DIR=$APIEXTRACTOR_DIR -DGeneratorRunner_DIR=$GENERATORRUNNER_DIR .
cd $PYSIDE_DIR
cmake -DShiboken_DIR=$SHIBOKEN_DIR/libshiboken -DGENERATOR=$GENERATORRUNNER_DIR .
cd $PYSIDE_TOOLS_DIR
cmake .
popd
Now, I don't know if this installation script is ok, but apparently everything works fine. Each component (apiextractor, generatorrunner, shiboken, pyside-qt and pyside-tools) gets compiled into its own directory.
The problem is that I don't quite understand how PySide gets into the system's python environment. In fact, when I start a python shell, I cannot import PySide:
>>> import PySide
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named PySide
Note: I am aware of the Installing PySide - OSX question, but that question is not relevant anymore, because it is about a specific a dependency on the Boost libraries, but with version 0.3.0 PySide moved from a Boost based source code to a CPython one.

I don't have any MacOS experience but assuming it's similar to any *nix, let's go:
About the script: Isn't it missing some "make, make install" commands? The version you posted just run cmake to configure the build. Also for testing, I set -DCMAKE_INSTALL_PREFIX= for all modules. That way everything is installed in the same place and CMake takes care of finding them for me, as long as I used the same install prefix for each one. The directory layout in your script is quite complicated and mixes build and source directories.
About finding PySide: once everything is properly compiled and installed, the directory where the "PySide" directory was installed must be available in the PYTHONPATH variable. In the example below,
Here's a simple version of a build script(works on Ubuntu):
#!/bin/bash
BUILD_ROOT=/tmp/pyside-build
INSTALL_PREFIX=/tmp/sandbox
function build_module {
cd $BUILD_ROOT
echo Cloning project $1 from url $2
git clone --depth 1 $2 $BUILD_ROOT/$1
BUILD_DIR=$BUILD_ROOT/$1/build
mkdir -p $BUILD_DIR
cd $BUILD_DIR
echo Configuring $1 build.
cmake -DCMAKE_INSTALL_PREFIX=$INSTALL_PREFIX ..
echo Configured $1. Starting build.
make LD_LIBRARY_PATH=$INSTALL_PREFIX/lib
echo Built $1. Installing.
make install
echo Successfully built and installed $1
}
rm -rf $BUILD_ROOT
mkdir -p $BUILD_ROOT
build_module apiextractor git://gitorious.org/pyside/apiextractor.git
build_module generatorrunner git://gitorious.org/pyside/generatorrunner.git
build_module shiboken git://gitorious.org/pyside/shiboken.git
build_module pyside-shiboken git://gitorious.org/pyside/pyside-shiboken.git
Run it and wait a while (Qt is quite big). :)
This script will download all packages into /tmp/pyside-build, build each one in its own "build" directory and install everything into /tmp/sandbox. Then, I just had to set PYTHONPATH to /tmp/sandbox/lib/python2.6/site-packages and PySide worked fine.

In answer to the original post...
What your script would have done is generate the necessary build files to build the pyside bindings, but it wouldn't have done the build itself. To do the build itself you'd need to execute a 'make', then a 'make install' in each of the build directories.
I've gotten most of the way through getting pyside 0.3.1 up and running on the Mac (SnowLeopard 10.6.3), but am hung up on the final compile step. My script is a bit less straightforward than yours, but in essence similar.
I have run into and worked around a number of problems to get to the final compile, and am hoping that I can help some folks along with the solutions/workarounds I've devised. Also, maybe collectively we can figure out how to get through the final step.
I'm going to include the build script that I'm using, and the log of the changes I had to make in the distro to get it running. But first, the step that I'm stuck on... mainly, I don't understand the error message, and the requested file doesn't seem to exist...
I hope this will help move support for the mac along...
I can't post this directly on stack overflow since its too long, so here is the link to the post on the mailing list over at pyside.
http://lists.openbossa.org/pipermail/pyside/2010-June/000812.html

While it's a been couple months since this question originally was asked I ran across the official PySide build script repo at:
http://qt.gitorious.org/pyside/buildscripts
The README covers the build process:
http://qt.gitorious.org/pyside/buildscripts/blobs/master/README
It seems to be fairly automatic with my only caveat so far being that it pulls down libxslt via brew - I can't say authoritatively if libxslt shipped with Snow Leopard or not - but it's definitely in Lion by default.
Seemingly the only manual install step is putting cmake on your system.