I have a django-based application that I'm running from a virtualbox-shared folder. When starting using 'runserver' I get an error indicating that a module could not be found. After copying the same exact code to a directory on the local filesystem, it starts and runs as expected.
Anyone seen anything like this when working with virtualbox and python?
It appears that module resolution is working differently when python is run from the mounted shared folder vs. the local folder, but I can't find a smoking gun that indicates whether or not it's caused by how that folder is mounted or python.
Thanks!
Try avoid putting your projects (large number of files/directories) on vboxsf (default synced folder).
vboxsf lacks support for symbolic / hard links, which will potentially cause problems (e.g. using git as version control). see the ticket #818 here, it is still NOT fixed.
There is a chance you're running into a problem with file system case sensitivity. It took me a couple of hours to figure this out myself. The shared folder is case insensitive, but the local folders are case sensitive since they are on a different file system (ext3/4). So you'll run into problems where python files in your current directory will override an import of the same name.
A simple example with pycrypto showing this (pip install pycrypto if you dont have it):
vagrant#virtualos:/mnt/shared_folder$ python -c 'from Crypto.PublicKey import RSA'
vagrant#virtualos:/mnt/shared_folder$ touch crypto.py
vagrant#virtualos:/mnt/shared_folder$ python -c 'from Crypto.PublicKey import RSA'
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: No module named PublicKey
If I do the same thing on a local (ext4) directory it works fine. It seems python has different import logic depending on what OS it is running on.
Unfortunately I have not found a good solution to this other than to manually copy files onto my VM instead of using shared folders.
One solution I found was to mount my shared folder with cifs into the VM. That seems to work flawlessly. I did not found a solution for the vboxsf.
Related
I'm currently using the Python 3.4 Mac OS X build from Python.org. I'm using a Python module that depends on a library that I built in Macports. The script does not run out-of-the-box:
Traceback (most recent call last):
File "magnetx.py", line 6, in <module>
import yara
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/yara.so, 2): Library not loaded: /usr/local/lib/libyara.3.dylib
Referenced from: /Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/yara.so
Reason: image not found
I can fix this if I set an environment variable
export DYLD_FALLBACK_LIBRARY_PATH="/opt/local/lib:$DYLD_FALLBACK_LIBRARY_PATH"
Unfortunately, it does not satisfy cx_freeze. It keeps looking in /usr/local/lib, when it should be looking in /opt/local/lib.
copying
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/yara.so
-> build/exe.macosx-10.6-intel-3.4/yara.so copying /usr/local/lib/libyara.3.dylib ->
build/exe.macosx-10.6-intel-3.4/libyara.3.dylib error: [Errno 2] No
such file or directory: '/usr/local/lib/libyara.3.dylib'
I could probably build Python in Macports, but that seems like it should be unnecessary. Any ideas on how to fix this?
On OS X, dependent libraries are referenced using absolute paths. The path that gets copied into your binary depends on the so-called "install name" of the library you link against at build time. In your case, the yara.so does not reference the library you would like it to load. Let's explore a couple of reasons why this could be the case, and a couple of ways to fix that:
I've verified that libyara.dylib as installed by MacPorts (on my system) has an install name of /opt/local/lib/libyara.0.dylib. Sometimes, build systems that don't use a cross-platform library build tool and don't expect the peculiarities of OS X mess this up (and use relative paths or /usr/local/lib). If this was the case, it would be a bug in the software's build system, which could be manually fixed using install_name_tool(1)'s -id flag (before linking against the library).
Your copy of yara.so may have been built against a different version of libyara.dylib that resides in /usr/local/lib. That would explain why your yara.so does not contain the correct absolute path to the MacPorts copy of libyara.dylib, but it would also prevent the error you're seeing from happening in the first place, unless you had a copy in /usr/local/lib at build time and deleted it later on. As you've already seen, you can instruct OS X' loader to also search different paths using the DYLD_* series of environment variables. My take on why this doesn't work for cx_freeze is that it doesn't pay attention to the DYLD_* series of variables.
If you are sure that the copy of libyara.dylib yara.so expects to find in /usr/local/lib is binary-compatible with the one in /opt/local/lib, you can manually modify the library load commands in yara.so to point to the latter path using install_name_tool(1)'s -change old new parameter, e.g. install_name_tool -change /usr/local/lib/libyara.3.dylib /opt/local/lib/libyara.0.dylib /Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/yara.so. This is essentially modifying the binary with the change the loader did for you when you set DYLD_FALLBACK_LIBRARY_PATH. Since the library major version numbers seem to be different, this may not be a safe assumption.
If you don't know whether yara.so is compatible with MacPorts' build of libyara.0.dylib, you can and should recompile yara.so. If the re-compile went right, you should be able to check the library load commands using otool -L yara.so and see the paths beginning with /opt/local in there (provided that otool -D /opt/local/lib/libyara.0.dylib correctly points to itself).
Edit: I've just re-checked and noticed that my MacPorts build's library version number differs from the one your system expects. That sounds a lot like case number 2 to me.
I'm developing an addon for XBMC that checks for files to delete based upon disk space availability. I am having trouble checking for disk space on my Windows 7 share from Linux-based operating systems, including Raspberry Pi, Ubuntu, etc. XBMC uses python 2.6 by the way.
My current code is as follows:
import os
loc1 = "smb://geert/e/Downloads/"
loc2 = "/home/"
stats = os.statvfs(loc)
print stats
In the code above loc1 is the path that gives trouble. It appears as if the statvfs module cannot handle smb:// paths, because I keep getting the error below. When I try loc2 everything is fine. I have searched high and low for a definitive answer to this question, but could not find any.
/usr/bin/python2.7 statvfstest.py
Traceback (most recent call last):
File "statvfstest.py", line 8, in <module>
print os.statvfs(loc)
OSError: [Errno 2] No such file or directory: 'smb://geert/e/Downloads/'
Steps I have tried:
I have tried the psutil module as I have seen recommended frequently in other questions on this site, but it appears to merely be a wrapper for the statvfs method and thus results in the same error message, only with a longer stack trace.
Mounted the e share and used the proper credentials. The share is visible from the file manager and shows the correct contents.
I have added credentials to loc1 in the form smb://user:pass#geert/e/Downloads/.
Any combination of the above three methods, all to no avail.
Could you please help me reliably test the amount of free space available on my Windows share, from a Linux PC, using smb network paths? If at all possible I would like to refrain from adding extra modules to my addon just for this feature, to ensure it stays lightweight.
Thanks in advance,
Geert
I'm trying to install the Chilkat library for Python in order to use its encryption functionality, but being new to Python in every possible way, I'm getting stuck entirely too early. I've installed the library as instructed by the docs and verified that the files are in the "right place" (/usr/local/lib/python2.7/site-packages/) on my Ubuntu 12.04 server.
I've also downloaded the test script. When I try to run it, however:
ImportError: No module named chilkat
I know this is stupid basic, but here I am. In the docs they do mention a possible issue with sys.prefix. That (presumably default, since I've never touched it) value on my machine is /usr. I moved everything there, but still get the same error.
Help? Where is the most "pythonic" place to put these files and how can I get Python to recognize them universally?
Thanks.
For anyone searching, I just ended up adding site-packages to my sys.path by adding a .pth file to dist-packages which was already in my path.
echo "/usr/local/lib/python2.7/site-packages" > /usr/local/lib/python2.7/dist-packages/site-packages.pth
I'm getting this error every time I run any python file in Eclipse using PyDev:
Traceback (most recent call last):
File "/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/site.py", line 73, in <module>
__boot()
File "/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/site.py", line 2, in __boot
import sys, imp, os, os.path
ImportError: Bad magic number in /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/os.pyc
I'm using python 2.6. This problem does not occur when I run python from the terminal (2.7 or 2.6). The only substantial thing I've changed since everything last worked, is an update to OSX Lion from Snow Leopard.
Similar discussions to this seem to suggest some kind of removal of the .pyc file, because of some kind of mismatch between what was originally using the .pyc files (I'm not entirely sure what a magic number is...). But I was a bit cautious of the idea of deleting os.pyc from the Frameworks directory. When the only other file is an os.pyo file (not sure what the difference it), rather than an os.py.
I've installed all OSX Lion updates, Eclipse updates and PyDev updates.
This problem occurs even with code such as :
if __name__ == '__main__':
pass
Any help resolving this would be appreciated!
Upgrading Python to 2.7.1, running "Update Shell Profile" command file which is located in Python directory and changing the Python settings in Netbeans according to new installation worked for me.
Yeah, you'll need to regenerate all your *.pyc and *.pyo files from the *.py files.
How you do this depends on how they were generated in the first place. Some packaging of python (and it's add-ons), such as in some Linux distros, gets a little too clever for its own good and keeps the original *.py files somewhere else and have their own build system for generating and placing the *.pyc and/or *.pyo files. In a case like that, you have to use that build system to regenerate them from the original *.py files.
FYI, here are a couple links on *.pyo files. They are the optimized versions of compiled python modules.
On OS X Lion, you should have a os.py file. This is likely the root cause of your error. The os.pyc file was generated from a different version of python than you are running now. Normally, I imagine the python interpreter would just regenerate the file from os.py. But for whatever reason, your system does not have that file.
I suspect that this is a small data point in a larger set of issues and would, in general, recommend a reinstallation of your operating system.
For comparison, I'm running 10.7.1, and I have the following:
[2:23pm][wlynch#orange workout] ls /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/os.*
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/os.py
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/os.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/os.pyo
As an aside, the *.pyo file is an optimized version of the python bytecode.
I'm typing at the console
from graphics import *
and I get this error
Traceback (most recent call last):
File "<pyshell#1>", line 1, in <module>
from graphics import *
ImportError: No module named graphics
I think your question comes from trying to work through Python Programming by John Zelle, with a Macintosh.
The first 4 chapters are great. But in chapter 5, where I tended to get stuck, he introduces Objects. The way he does that is kind of interesting. He has created a python module which he calls “graphics.py” which you can download from his website.
This module (I’ve attached a link to it below) is a python program written by Mr. Zelle. It creates the tools for making very simple shapes and getting used to the basic concepts with graphics and it also serves as a more tangible way of introducing Objects.
However I was confused, it took me a while to realize that “graphics.py” was a pedagogical program Mr. Zelle created, and not something that comes bundled with MacPython. This confusion stems from the fact that the programs in Chapter 5 all begin with “import graphics” which looks very similar to the “import math” command at the beginning of every program in the 3rd chapter.
The key difference is that “import math” imports the standard mathematics library that came pre-bundled with MacPython. But “import graphics” refers to John Zelle’s own “graphics.py” module, which you have to download and instal first.
It took me a while to figure that out….
Then once I did, I went to his website, copied the program from this website:
http://mcsp.wartburg.edu/zelle/python/graphics.py
...into IDLE and then saved it as graphics.py
This is where it got maddening...
On Windows if you just put the graphics.py file in the same folder as Python, it can find the file and use it without a problem.
Here is what the book said, that made me feel so crazy:
“To use the graphics module (graphics.py) you need to place this file where Python can locate it. >One simple approach is to put it in the same folder where you keep your Python programs. Starting >Python in this folder will also let you import the graphics library to experiment interactively.
Alternatively, you can place the graphics.py file in a system-wide directory so that it is >available for import no matter what directory Python starts in. The standard directory for placing >local additions to Python is the site-packages directory. On my Windows installation, the complete >path to the folder is:
C:\Python23\Lib\site-packages
On my Linux system, the file resides in:
/usr/local/bin/lib/python2.3/site-packages."
On a windows OS, all that you have to do is go to Python.org and download Python for Windows and put that graphics.py file in the main folder, and boom, you’re golden, NOT SO FOR MACINTOSH!!!!
2 years ago, this is where I got totally stuck, because I had no idea about site paths, or directories; I just pointed and clicked; I didn’t know about the Unix system underneath the Macintosh Aqua GUI.
And the book gives no instructions for what to do if you have a Macintosh, and I hit a wall.
But when I went at it again a few weeks ago, those directories made more sense to me, because I spent the spring and summer playing with a guidebook to using the UNIX command shell on my Mac.
So I realized that my problem had nothing to do with Tkinter, It was just that graphics.py needed to be in the right directory. I couldn’t just put it in the folder next to IDLE as I could on a Windows machine. I needed to find the right directory.
Since OSX is built on a UNIX base, I thought that the file path might be the same as Linux. Sadly, there was no “local”, “bin” after the “user” directory. But its not quite the same in OSX.
Instead you can use IDLE itself to find out which path directories it uses.
You type this:
import sys
print sys.path
and BOOM, it spits out a whole bunch of directories, confusingly formatted like this
['', '/Users/jamesbarnard/Documents', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages’,
'/Library/Python/2.7/site-packages’]
But when I looked closer I noticed the directory “site-packages” which looked a lot like the “site-packages” on the Linux and Windows command lines.
So I pulled out that directory chain
['', '/Users/jamesbarnard/Documents', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload’,
'/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages', ‘
/Library/Python/2.7/site-packages’]
Then using the UNIX shell I followed it down, and then I did the same thing in the Aqua interface.
And there, buried 8 levels down in the directory, amidst hundreds of other files, I placed my graphics.py file.
Then I went back into IDLE, typed in “import graphics”
AND IT WORKED!!
If you are having this problem. I hope this solution saves you my headache.
did you follow the instructions to install the graphics module and is it in your pythonpath?
Type how to install graphics.py in Google.
http://www.google.co.in/search?sourceid=chrome&ie=UTF-8&q=how+tooinstall+gaphics.py#sclient=psy-ab&hl=en&source=hp&q=how+to+install+gaphics.py&pbx=1&oq=how+to+install+gaphics.py&aq=f&aqi=&aql=&gs_sm=s&gs_upl=0l0l0l24645l0l0l0l0l0l0l0l0ll0l0&bav=on.2,or.r_gc.r_pw.r_cp.,cf.osb&fp=344adf6de4d60025&biw=1366&bih=600
Click on the third link
http://mcsp.wartburg.edu/zelle/python/graphics.py
Copy that file which got downloaded to your lib folder in Python32 in C drive.
The error will not occur now.
Short cut to installing graphics.py via command line and/or terminal window. run the following command in admin rights in windows.
this will allow you to import graphics
pip3 install --user http://bit.ly/csc161graphics
ps. Im running python 3.6.2 on Atom. Hope this helps some.
Perhaps you forgot to run python setup.py -install after downloading the module.
You can also put graphics.py in the same folder where you started the python shell.
http://mcsp.wartburg.edu/zelle/python/graphics.py
I recently had this issue where I typed (and pasting the code into the interpreter did not work either) 'import graphics' into the interpreter and the error I got was:
Traceback (most recent call last):
File "", line 1, in
from graphics import *
ImportError: No module named graphics
I took the following steps to fix the error:
-Go to: http://mcsp.wartburg.edu/zelle/python/
-Right click on the link 'graphics.py and click 'save target as'
-save in the directory 'Python33', along with the 'chaos.py' file. This step is important that you do not save it in other locations (it may work if you save it in other locations I decided to save it in this location).
Hope this helps.