I am trying to deploy an app on google app engine using bottle, a
micro-framework, similar to flask. I am running on ubuntu which comes
with python 2.7 installed but GAE needs version 2.5, so I installed
2.5. I then realized I didn't use make altinstall so I may have a
default version problem now. But my real problem is that when I try to
use the gae server to test locally I get the following error:
Traceback (most recent call last):
File "/opt/google/appengine/dev_appserver.py", line 77, in <module>
run_file(__file__, globals())
File "/opt/google/appengine/dev_appserver.py", line 73, in run_file
execfile(script_path, globals_)
File "/opt/google/appengine/google/appengine/tools/
dev_appserver_main.py", line 156, in <module>
from google.appengine.tools import dev_appserver
File "/opt/google/appengine/google/appengine/tools/
dev_appserver.py", line 94, in <module>
import zlib
ImportError: No module named zlib
Can you help me with this?
How did you build Python 2.5? If you built it from sources yourself, there's a good possibility the zlib module didn't get built because the necessary libraries and header files weren't installed on your system.
On Ubuntu, you need (I think) the zlib1g-dev package.
This will be true for a variety of other modules as well (for example, without the appropriate OpenSSL development libraries/headers in place, you won't get the ssl module either).
Someone may also have a python2.5 package for your version of Ubuntu (although neither Natty or Maverick appear to have one in the official repositories).
Before figuring out that using a post-2.5 Python worked just fine as long as you didn't use any post-2.5 language features or packages (or additions to package), I wrote up a walkthrough for building 2.5 for Ubuntu here. It includes the bit you need for zlib.
I'm now happily developing on Ubuntu using Python 2.6.5 (with SDK 1.5.4).
Related
When I run some commands, which work, for example neofetch, it gives me a Python error.
username#host:~$ as
Traceback (most recent call last):
File "/usr/lib/command-not-found", line 28, in <module>
from CommandNotFound import CommandNotFound
File "/usr/lib/python3/dist-packages/CommandNotFound/CommandNotFound.py", line 19, in <module>
from CommandNotFound.db.db import SqliteDatabase
File "/usr/lib/python3/dist-packages/CommandNotFound/db/db.py", line 5, in <module>
import apt_pkg
ModuleNotFoundError: No module named 'apt_pkg'
It does that whenever I type an invalid command. This started happening after I installed Python 3.9. I am running Kubuntu with Python 3.10 installed by default.
Modern Linux distributions tend to use a lot of python scripts for internal use; for this reason python gets installed with a plethora of libraries.
The error you are getting is because you replaced that fairly complete system python with a version of your own choosing without providing all the libraries the original came with.
The error you see is emitted by /usr/lib/command-not-found, a script using python3 as found in the system path.
I strongly recommend that you re-install the original python packages and use e.g. anaconda for your specific python needs.
The main takeaway from this is:
DON'T MESS WITH THE SYSTEM PYTHON.
try to find which python are you using using which python and uninstall the first python interpreter it finds.
I'm bundling a pygame app using py2app. The bundling works and the resulting bundle runs on my mac just fine. It also used to run on another person's mac just fine. However, recently I've started getting this error (from the console) when trying to run the bundle on his computer:
Traceback (most recent call last):
File "/Users/.../tmp/withconsole.app/Contents/Resources/__boot__.py", line 316, in <module>
_run()
File "/Users/.../tmp/withconsole.app/Contents/Resources/__boot__.py", line 311, in _run
exec(compile(source, path, 'exec'), globals(), globals())
File "/Users/.../tmp/withconsole.app/Contents/Resources/withconsole.py", line 18, in <module>
pdb.set_trace()
File "bdb.pyc", line 53, in trace_dispatch
File "bdb.pyc", line 88, in dispatch_return
File "pdb.pyc", line 190, in user_return
File "pdb.pyc", line 210, in interaction
File "cmd.pyc", line 142, in cmdloop
File "pdb.pyc", line 279, in onecmd
File "cmd.pyc", line 218, in onecmd
File "pygame/macosx.pyc", line 10, in <module>
File "pygame/sdlmain_osx.pyc", line 14, in <module>
File "pygame/sdlmain_osx.pyc", line 10, in __load
ImportError: dlopen(/Users/.../tmp/withconsole.app/Contents/Resources/lib/python2.7/lib-dynload/pygame/sdlmain_osx.so, 2): Symbol not found: _OBJC_CLASS_$_NSObject
Referenced from: /Users/.../tmp/withconsole.app/Contents/Resources/lib/python2.7/lib-dynload/pygame/sdlmain_osx.so
Expected in: /usr/lib/libobjc.A.dylib
in /Users/.../tmp/withconsole.app/Contents/Resources/lib/python2.7/lib-dynload/pygame/sdlmain_osx.so
2013-11-09 06:19:50.794 withconsole[2797:1c03] ogclient Error
I even tried running an older bundle that used to work, yet now it no longer works! I'm 95% certain of that, anyway.
In any case, what's the issue and how can I fix it?
A standalone app from py2app creates its baked-in Python interpreter from whichever version of Python you use for py2app.
If you use, say, a Python built to run on any OS X 10.6 or later, the application (so long as it doesn't use any post-10.6 features) will also run on any OS X 10.6 or later. If you use a Python built to run on one particular 10.8 machine, the application will very likely not work on anything earlier than 10.8, and may not even work on other 10.8+ machines.
On top of that, if you're using any C extension modules that you built against C libraries that you built yourself, if those C libraries were built for your particular machine, they'll probably cause the same problem.
You built your Python interpreter with Homebrew. And maybe your SDL as well, which pygame depends on. And possibly other things. By default, Homebrew builds everything to run on your particular machine, not to be redistributable. Hence the problem.
To build an app that can run on 10.7 machines, you need to either build Python, SDL, etc. against the 10.7 SDK, or build it against a later API and specify -mmacosx-version-min=10.7. (There are a few other issues that can come up, but I'm pretty sure none of them affect CPython, so let's keep it simple.)
That will automatically set things up so any C extension modules you build use the same SDK and version settings, so you shouldn't have to worry about those. But you do have to worry about any C libraries you built that those extension modules depend on. For example, pygame links against libSDL, and if you built SDL for your local machine only, pygame isn't going to work on someone else's machine.
It's possible to get Homebrew to create SDK builds, but not always that easy. It's easier to just build Python manually and pass the right --configure flags. But it's even easier to take a binary that someone else has already built for portability and use that.
The official Python installers at python.org are built for 10.6+. The official SDL development libraries are built for 10.5+. Hopefully the same is true for other things you're depending on. If so, just brew uninstall (or, if you're wary and want to be able to undo this later, brew unlink) everything, run the binary installers, reinstall all the Python modules you need for the new Python, and py2app with it.
I wrote this all in general terms. From the output, it looks like the specific problem you're hitting on this particular run on your friend's particular 10.7 machine is that the SDL wrappers are depending on features of the ObjC runtime that didn't exist in 10.7. So, it's possible that just using a 10.7-friendly SDL, and your existing Python, would be sufficient. But I think you're better off using 10.7-friendly everything if at all possible.
If you're wondering what exactly the SDK does, the SDK Compatibility Guide in Apple's official docs explain the technical side of it pretty well, and there are a zillion blog posts like this one that explain the practical parts, but I'll try to summarize.
Each SDK is just a directory that has its own /usr/include, /usr/lib, /System/Library/Frameworks, and a few other things inside. When you build against an SDK, you end up compiling against its header files instead of your system's, and linking against its dylibs instead of your system's. This prevents you from using any new features added since 10.6 (with a nice compiler error, instead of a successful build that then won't start on half your users' machines). And it makes sure that, if you don't use any such new features, your program doesn't have load-time dependencies on anything that didn't exist in 10.6.
I'm bundling a pygame app using py2app. The bundling works and the resulting bundle runs on my mac just fine. It also used to run on another person's mac just fine. However, recently I've started getting this error (from the console) when trying to run the bundle on his computer:
Traceback (most recent call last):
File "/Users/.../tmp/withconsole.app/Contents/Resources/__boot__.py", line 316, in <module>
_run()
File "/Users/.../tmp/withconsole.app/Contents/Resources/__boot__.py", line 311, in _run
exec(compile(source, path, 'exec'), globals(), globals())
File "/Users/.../tmp/withconsole.app/Contents/Resources/withconsole.py", line 18, in <module>
pdb.set_trace()
File "bdb.pyc", line 53, in trace_dispatch
File "bdb.pyc", line 88, in dispatch_return
File "pdb.pyc", line 190, in user_return
File "pdb.pyc", line 210, in interaction
File "cmd.pyc", line 142, in cmdloop
File "pdb.pyc", line 279, in onecmd
File "cmd.pyc", line 218, in onecmd
File "pygame/macosx.pyc", line 10, in <module>
File "pygame/sdlmain_osx.pyc", line 14, in <module>
File "pygame/sdlmain_osx.pyc", line 10, in __load
ImportError: dlopen(/Users/.../tmp/withconsole.app/Contents/Resources/lib/python2.7/lib-dynload/pygame/sdlmain_osx.so, 2): Symbol not found: _OBJC_CLASS_$_NSObject
Referenced from: /Users/.../tmp/withconsole.app/Contents/Resources/lib/python2.7/lib-dynload/pygame/sdlmain_osx.so
Expected in: /usr/lib/libobjc.A.dylib
in /Users/.../tmp/withconsole.app/Contents/Resources/lib/python2.7/lib-dynload/pygame/sdlmain_osx.so
2013-11-09 06:19:50.794 withconsole[2797:1c03] ogclient Error
I even tried running an older bundle that used to work, yet now it no longer works! I'm 95% certain of that, anyway.
In any case, what's the issue and how can I fix it?
A standalone app from py2app creates its baked-in Python interpreter from whichever version of Python you use for py2app.
If you use, say, a Python built to run on any OS X 10.6 or later, the application (so long as it doesn't use any post-10.6 features) will also run on any OS X 10.6 or later. If you use a Python built to run on one particular 10.8 machine, the application will very likely not work on anything earlier than 10.8, and may not even work on other 10.8+ machines.
On top of that, if you're using any C extension modules that you built against C libraries that you built yourself, if those C libraries were built for your particular machine, they'll probably cause the same problem.
You built your Python interpreter with Homebrew. And maybe your SDL as well, which pygame depends on. And possibly other things. By default, Homebrew builds everything to run on your particular machine, not to be redistributable. Hence the problem.
To build an app that can run on 10.7 machines, you need to either build Python, SDL, etc. against the 10.7 SDK, or build it against a later API and specify -mmacosx-version-min=10.7. (There are a few other issues that can come up, but I'm pretty sure none of them affect CPython, so let's keep it simple.)
That will automatically set things up so any C extension modules you build use the same SDK and version settings, so you shouldn't have to worry about those. But you do have to worry about any C libraries you built that those extension modules depend on. For example, pygame links against libSDL, and if you built SDL for your local machine only, pygame isn't going to work on someone else's machine.
It's possible to get Homebrew to create SDK builds, but not always that easy. It's easier to just build Python manually and pass the right --configure flags. But it's even easier to take a binary that someone else has already built for portability and use that.
The official Python installers at python.org are built for 10.6+. The official SDL development libraries are built for 10.5+. Hopefully the same is true for other things you're depending on. If so, just brew uninstall (or, if you're wary and want to be able to undo this later, brew unlink) everything, run the binary installers, reinstall all the Python modules you need for the new Python, and py2app with it.
I wrote this all in general terms. From the output, it looks like the specific problem you're hitting on this particular run on your friend's particular 10.7 machine is that the SDL wrappers are depending on features of the ObjC runtime that didn't exist in 10.7. So, it's possible that just using a 10.7-friendly SDL, and your existing Python, would be sufficient. But I think you're better off using 10.7-friendly everything if at all possible.
If you're wondering what exactly the SDK does, the SDK Compatibility Guide in Apple's official docs explain the technical side of it pretty well, and there are a zillion blog posts like this one that explain the practical parts, but I'll try to summarize.
Each SDK is just a directory that has its own /usr/include, /usr/lib, /System/Library/Frameworks, and a few other things inside. When you build against an SDK, you end up compiling against its header files instead of your system's, and linking against its dylibs instead of your system's. This prevents you from using any new features added since 10.6 (with a nice compiler error, instead of a successful build that then won't start on half your users' machines). And it makes sure that, if you don't use any such new features, your program doesn't have load-time dependencies on anything that didn't exist in 10.6.
So i had python 2.7.2 on my server and i needed to update it to python 2.7.3. So i've tried to remove the 2.7.2 version and then install the new one using the sources. I wasn't able to remove the 2.7.2 version cause the system uses it to run crucial services on server, so i installed the 2.7.3 version in hope that after that i would be able to remove the old version. Still i cant remove the old version, although i'm able to execute the python 2.7.3 when i install any module i cant import it. I added the path to sys.path and i started finding the module but importing it causes another errors.
My python executes the /usr/local/bin/python which is the 2.7.3 version where the problems are.
If i try to execute python like this /usr/bin/python it executes the old version and everything works fine there, i can import the new installed modules.
So what can i do to make python 2.7.3 work?
I've searched a lot of tutorials and tried things like add the library in .pth files on python and i started finding the modules but when importing it i get errors like this:
>>> import numpy
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python2.7/dist-packages/numpy/__init__.py", line 137, in <module>
import add_newdocs
File "/usr/local/lib/python2.7/dist-packages/numpy/add_newdocs.py", line 9, in <module>
from numpy.lib import add_newdoc
File "/usr/local/lib/python2.7/dist-packages/numpy/lib/__init__.py", line 4, in <module>
from type_check import *
File "/usr/local/lib/python2.7/dist-packages/numpy/lib/type_check.py", line 8, in <module>
import numpy.core.numeric as _nx
File "/usr/local/lib/python2.7/dist-packages/numpy/core/__init__.py", line 5, in <module>
import multiarray
ImportError: /usr/local/lib/python2.7/dist-packages/numpy/core/multiarray.so: undefined symbol: PyUnicodeUCS4_AsUnicodeEscapeString
Thanks for the help
EDIT PROBLEM SOLvED
So to solve the missing import modules i created a .pth file under /usr/local/lib/python2.7/site-packages/ with the directories where the python modules are and the python starts to find them.
To fix the comptability problems you can install python from sources and specify the unicode doing ./configure --enable-unicode
more information here
Do not EVER mess with system python, EVER.
What you should do is install python 2.7.3 with a --prefix into your home directory, then use virtualenv -p /home/myuser/path/to/python.
In any case, using virtualenv to run your own application is almost always a good idea, as it avoids polluting the system package directories with libraries you use in your own applications.
It looks like the modules you've installed were built against your old version of Python, or at least a version incompatible with your newer installation. The import error you're seeing at the bottom is the numpy module searching for a symbol that is not in your build of 2.7.3. There is further information here.
If possible, it's usually way easier to upgrade Python with a package manager. That way, if anything on your system depends on Python, but does not need exactly 2.7.2, then Python can be easily upgraded without disturbing anything. I'm guessing that either your server doesn't have a newer version of Python available and you can't add new repositories, or you don't have access to a package manager. If using packages is possible, I would go ahead and remove what you've built from source (the command should be 'make clean' if Python uses GNU Make).
If that isn't an option, then there should be a way to compile Python, but not install it into system directories. Then you could add a symlink for users, and make sure that symlink has precedence in their path.
When installing python use the following steps
using prefix to specify the installation directory
./configure --prefix=/usr/bin/python
make
make install
Then everytime u run a new Terminal u have specify
export PATH="$PATH:/usr/bin/"
to tell where is the installation directory of Python
This way u can use any number of pythons
You can install python libs from R. It works for me.
For example, to install numpy library from R type:
system('python -m pip install -U numpy')
I am on a Windows 7 64bit machine, using Python 2.7 and I am trying to use the python database library in robotframework. I have previously used a java library file but now I want to use the python library.
I have gone to github and downloaded version 0.6.
I have also installed a setup file and MySQL-python from here
However when I try to install the database library (using python setup.py build) I get the following error:
Traceback (most recent call last):
File "setup.py", line 25, in <module>
from DatabaseLibrary import __version__
File "src\DatabaseLibrary\__init__.py", line 15, in <module>
from connection_manager import ConnectionManager
File "src\DatabaseLibrary\connection_manager.py", line 16, in <module>
from robot.api import logger
ImportError: No module named api
Why do I not have robot.api and how do I get it and install it? Or is there an easier way to install the python database library?
It seems that the Database library uses Robot Framework internals, but does not list Robot Framework as it's dependency. The robot.api package was introduced in RF 2.6, so upgrading/installing the latest Robot Framework (from project pages) should resolve your issue
First ensure the integrity of your module before trying to install. In order to install a module using distutils (setup.py) you need to run this command as an administrator:
python setup.py install
That should run the setup and report back to you any missing dependencies.
Alternatively, you can install PIP from this location: PIP Project home page. Their page provides instructions how to install PIP, it's a package manager for Python, similar to PEAR for PHP, CPAN for Perl or gem for ruby. When you have it installed you can install packages with this command:
pip install <module>
The issue was I did not have the "API" folder in the "Robot" folder in "Python27\Lib\site-packages" as I did not have the latest version of RF. And logger is a new logging API for Robot Framework 2.6 since Oct 2011. (As janne as pointed out)
Two fixes for this issue seem to be:
Tested and worked but not recommended unless you dont want to update RF: Edit the 2 files "connection_manager.py" and "query.py" in "robotframework-databaselibrary-0.6" so that there is no dependency on the Robotframework logger. This is a easy and quick edit, where you replace the "from robot.api import logger" to "import logging" and "logger" to "logging"
See "http://robotframework.googlecode.com/hg/doc/userguide/RobotFrameworkUserGuide.html#programmatic-logging-apis" for more detail.
Reinstall Robotframework and ensure the "API" folder is created. This is recommended as it is the best approach.
(Added as an answer as too long for a comment)