Okay I am newer to python and have been researching this problem but I can't find anything like it so I am not sure what is going on.
I am creating a program that involves sage and it has a message cue. We have this set up on a development machine, so I know it works but I was wanting to set it up on my own computer so I could get a better understanding of how it all works and make it easier to develop for myself.
To start up sage, we run a script that calls sages main binary file and passes it an executable .py file. (./sage/sage ./sage_server.py) This creates an error in the sage_server.py file:
Traceback (most recent call last):
File "./sage_server.py", line 23, in <module>
from carrot.messaging import Publisher
ImportError: No module named carrot.messaging
But whenever I run that file just in the terminal (./sage_server) the import works fine and isn't until line 27 that there is an error when it tries to import something from sage.
Does anyone know what would cause the error when it is being called by something else? I am very lost as to what would be causing this.
Sage has its own python, separate from the system libraries. This "carrot" module, whatever it is, must be installed in whatever python ./sage_server.py uses, but not in Sage.
You should be able to use either
[your-sage] -sh
to start up a Sage shell and use easy_install, or you could get whatever carroty package you're using, find its setup.py file, and then run
[your-sage] -python setup.py install
where obviously your-sage is the path to your sage.
Things get a little trickier if the install process isn't setup.py-based.
Related
I am having a problem getting an informative traceback when I run a script with the -m flag. I am using the -m flag so that I can properly use relative imports throughout my package. When an error comes up, stdout does tell me the nature of the exception but not the location, such as file and line number.
/usr/bin/python: Error while finding spec for 'bin.load_ref_exps.py'
(: 'module' object has no attribute
'path')
I would very much like to be able to run the script directly with a full traceback to quickly debug what is going on.
Any ideas on how to run the script in a way that doesn't break all the package based relative imports and still gives me a full traceback?
Thanks!
If you use -m, you shouldn't specify the .py extension, since you are specificying a module name, not a file per se. See the documentation.
I'm trying to get the websockify 0.6.0 running on windows but without any luck,
I have tried python websockify.py 1501 10.0.0.141:1501 but its not good, getting errors , like that:
Traceback (most recent call last):
File "websockify.py", line 1, in <module>
run
NameError: name 'run' is not defined
I also tried Compiling Websockify as Windows Executable , but this also didn't work
I use the following command run.exe 1501 10.0.0.141:1501 and it looks promising at the beginning, outputting the following to the console:
WARNING: no 'resource' module, daemonizing is disabled
WebSocket server settings:
- Listen on :1501
- Flash security policy server
- No SSL/TLS support (no cert file)
- proxying from :1501 to 10.0.0.141:1501
but then after trying to connect using the following from the browser ws://localhost:1501
**it outputs the following error
Traceback (most recent call last):
File "run", line 5, in <module>
File "websockify\websocketproxy.pyc", line 419, in websockify_init
File "websockify\websocket.pyc", line 1018, in start_server
UnboundLocalError: local variable 'exc' referenced before assignment
Any idea on how to use the websockify on windows / or how to use the compiled websockify as windows executable ?
The easiest way to get websockify working on Windows is to use the Node.js version of websockify (in the other/js directory). It works perfectly out of the box, with no shenanigans required.
To address this, use the modified following commands for your example source, start from the beginning of each step and see if it helps:
Firstly, install Portable Python 2.7
You then need to modify the setup.py (It looks like this is why you are getting your first error, as you may not have defined run):
from setuptools import setup, find_packages
# add (line 2):
import py2exe
setup(name=name,
# add (line 10):
console=['run'],
Ensure the above has executed correctly by inspecting setup.py and ensure it includes run.
In your local code, import the resources module to allow you to monitor, measure and control system resources utilized by your program
import resource
Inspect your local variable exc and ensure you have assigned a value to it before calling it (I'm guessing you may have attributed a system variable to it, but python was unable to do so as you did not have resources imported, and as such it was not assigned). If you like, put up an example of your code in the comment to this response and I'll take a closer look at this part.
Back to your source guide, navigate to the websockify folder in command prompt, then execute the following to compile websockify:
[Your path to Portable Python install]\App\python.exe setup.py py2exe --includes numpy
You will now see in the websockify directory a new dir 'dist' which contains the compiled exe. An example provided is:
run.exe 5901 localhost:5900
There is also a guide here to run websockify as a Windows Service if this suits (again mentioned in your source).
----Further edit for more detail----
Open up the two files that seem to be giving you issues (websockify\websocketproxy.pyc and websockify\websocket.pyc and ensure that any reference to a variable called "exc" is referenced after it has been assigned a value (small chance of an issue if you have not yet modified these files.
I believe that your code is relying upon making and monitoring changes to the system resources (such as ports etc) and you are not allowing your code to have these permissions, so it needs the resources module. If you are calling run.exe from a program (what I called your local code) then you need to import resources at the top. If you are just straight up calling the run.exe program from a command line, then try making this new program and see if this helps. If not, send me the contents of your websockify folder and run.exe and I will take a look
# Program Name: goAndRun.py
# Code:
import sys, string, os, arcgisscripting, resource
os.chdir( 'C:\\[Path_to_the_dir_containing_run.exe]' )
os.system( '"C:\\[Path_to_the_dir_containing_run.exe]\run.exe, 5901 localhost:5900"' )
And then use the command:
python goAndRun.py
Not being in your environment, I cannot tell if this will execute exactly as I have written it. The last line may also be:
os.system( '"C:\\[Path_to_the_dir_containing_run.exe]\run.exe"', '5901 localhost:5900' )
On my CentOS5 server, I have both Python2.4 and 2.6 (2.4 is required for yum to work). I'm not sure what happened, but suddenly the system gets very confused every time I try to run a file whose modules are loaded into the 2.4 site-packages directory. I checked the PYTHONPATH/sys.path and it looks like everything was overwritten with 2.6 environment data instead.
It didn't used to do this. I simply declared /usr/bin/python or /usr/bin/python26 in the shebang statement at the beginning of the script and it always found the correct modules just fine.
Is there a way for the PYTHONPATH variable to be dynamic and load different paths based on which python interpreter is running?
Otherwise I'm going to have to manually edit the path in every application, which seems like overkill.
It started after installing web.py (which I love, by the way).
Traceback:
As someone commented below, I changed the shebang to be #!/usr/bin/env python for this program:
Traceback (most recent call last):
File "/usr/bin/linkchecker", line 24, in ?
import codecs
File "/usr/lib/python2.6/codecs.py", line 268
return (b"", 0)
^
Another example, trying to use yum:
Traceback (most recent call last):
File "/usr/bin/yum", line 5, in ?
import yum
File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 21, in ?
import os
File "/usr/lib/python2.6/os.py", line 758
bs = b""
^
I've noticed a couple programs not confounded by the b"" syntax, and all of them are programs meant to use 2.4 that are for some reason using 2.6. If I try to make the program use the 2.6 interpreter it is able to understand that syntax, but then can't find any of the other modules (which are in the 2.4 site-packages directory).
I don't know what that syntax is, as they were written into modules which I got from sourceforge, however they were working last week. I am not sure what changed.
Thanks,
Tom
First of all, use virtualenv to isolate packages for multiple Python installations. Most of your problems will go away immediately.
Second, as Ibp has recommended in his answer, change the shebang line to use the "currently active" python binary so that it will work across multiple interpreters.
Instead of using the shebang (first bytes of the file)
#!/usr/bin/python
use the shebang
#!/usr/bin/env python
Edit: I second Noufal's suggestion to use virtualenv.
I've recently come back to a project having had to stop for about 6 months, and after reinstalling my operating system and coming back to it I'm having all kinds of crazy things happen. I made sure to install the same version(2.6) of python that I was using before.
It started by giving me strange tkinter error that I hadn't had trouble with before, the program is relatively simple and the 2 or 3 bugs that were left when i quit, I had documented and weren't related to the interface.
Things got even weirder when the same error would pop up even after I had removed the offending section of code. In fact, the traceback pointed to a line that didn't even exist in the module it was referencing, eg: line 262 when the module was only 200 lines long.
After just starting a completely new file for the main module and copy/pasting it finally recognized that the offending code was gone and I stopped getting the error only to find that any updates to the code I made in another module didn't show up when I restarted the program through the shell. (I didn't forget to save.) After fiddling with this, of course, the old interface error came back, only in a different section of code that had been working previously.
In fact, if I revert back to the files I had six months ago, the program works fine. As soon as I change anything in the main module, however, the interface bug comes back.
Here's the original error:
Exception in Tkinter callback
Traceback (most recent call last):
File "C:\Python26\lib\lib-tk\Tkinter.py", line 1410, in __call__
return self.func(*args)
File "C:\PyStuff\interface.py", line 202, in dispOne
__main__.top.destroy()
File "C:\Python26\lib\lib-tk\Tkinter.py", line 1938, in destroy
self.tk.call('destroy', self._w)
TclError: can't invoke "destroy" command: application has been destroyed
I'm guessing something else is going on here other than my own poor programming. Anyone have any ideas?
Edit: Thinking back, I believe I read something about it being a bad idea to run Tkinter programs through IDLE's shell, and it appears, at least, that the TclError has vanished if I instead start the main module by double clicking the .pyc file. Perhaps my problems were just a combination of that plus the timestamp/PYTHONPATH issues mentioned below by Chris Atlee and Vlad?
I've had something similar happen. The cause for my problems was that my source control software (hg) was setting the date of files to a date in the past. Because of this, python chose to use previously generated .pyc files which had newer timestamps.
The solution was to delete all the .pyc files before testing the code.
Check your PYTHON_PATH variable, you probably have an older version of the file.
Also start your python interpreter and type the following commands to check the path:
import sys
print sys.path
Take a careful look at the output and make sure you don't have any old directories sitting there.
Python came pre-installed on my macbook and I have been slowly getting acquainted with the langauge. However, it seems that my configuration of the re library is incorrect, or I simply misunderstand something and things are amiss. Whenever I run a python script with "import re", I recieve the following error:
Traceback (most recent call last):
File "regex.py", line 2, in <module>
import re
File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/re.py", line 4, in <module>
# re-compatible interface for the sre matching engine
AttributeError: 'module' object has no attribute 'compile'
What gives!
Pretty mysterious problem, given that line 4 in that file (and many other lines around that line number) is a comment (indeed the error msg itself shows that comment line!-) so even with the worst misconfiguration I'd be hard put to reproduce the problem as given.
Let's try to simplify things and check how they may (or may not) break. Please open a Terminal, mkdir a new empty directory somewhere and cd into it (so we know there's no filename conflict wrt modules etc), at the bash prompt unset PYTHONPATH (so we know for sure that isn't interfering), unset PYTHONSTARTUP (ditto); then type the command:
$ python -c'import re; print re.__file__'
It should emit the line:
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/re.pyc
does it? If so, then we can keep rooting around to understand what name clash (or whatever) caused your original problem. If the problem persists under such "clean" conditions then your system is jinxed and I would reinstal Mac OS X Leopard if I were in your shoes!