During a minion deployment, a UnboundLocalError is raised by the git library used as a dependency of salt
An exception occurred in this state: Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/salt/state.py", line 1594, in call
**cdata['kwargs'])
File "/usr/lib/python2.7/dist-packages/salt/loader.py", line 1491, in wrapper
return f(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/salt/states/git.py", line 519, in latest
if remote_rev_type == 'sha1':
UnboundLocalError: local variable 'remote_rev_type' referenced before assignment
It is very unclear to know what happen here. Any clue?
This was a bug in the salt-stack library. Variable remote_rev_type was not initialized in all execution paths.
From the looks of the current salt-stack source code, I'd say it has been fixed.
Related
I keep getting the error listed below. The problem isn't that there's an error. It's that the segment of code that is throwing the error no longer exists. I modified it to address the error. It now calls a method .cooridnates() rather than the propery .extent, but it seems to keep running the old code some how (shown in bold). I tried swapping out my IDE and restarting the machine, but still nothing. It's not currently tracked in a repo. So I'm out of ideas. It's a windows 10 machine.
Traceback (most recent call last):
File "C:\Program Files\ArcGIS\Pro\bin\Python\envs\PGE_Pro_Py3\lib\site-packages\arcgis\geometry\_types.py", line 183, in __getattr__
return self.__getitem__(name)
File "C:\Program Files\ArcGIS\Pro\bin\Python\envs\PGE_Pro_Py3\lib\site-packages\arcgis\geometry\_types.py", line 190, in __getitem__
return dict.__getitem__(self, k)
KeyError: 'extent'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File \\rcnas01-smb\NRM_DataTeam\e_Scripts\~DS\Defensible_space_pre_inspection_form_export_2022_20211029.py, line 192, in <module>
map_server_response = temp.site_map(item_webmap, 'Asset Centroid', "ASSET_NAME = '{}'".format(which_one))
File \\rcnas01-smb\NRM_DataTeam\e_Scripts\template_fxn.py, line 154, in site_map
**extent = sdf_zoomer.spatial.bbox.buffer(400).extent**
File "C:\Program Files\ArcGIS\Pro\bin\Python\envs\PGE_Pro_Py3\lib\site-packages\arcgis\geometry\_types.py", line 186, in __getattr__
"'%s' object has no attribute '%s'" % (type(self).__name__, name)
AttributeError: 'Geometry' object has no attribute 'extent'
Thanks everyone for the replies. I figured out the issue. Some how an old copy of the imported function library was saved in another directory that was also appended in. The program refenerced the first appended path with the old file first. So as I update the script the program continue to used the old copy.
I'm planning to use the Language-check module for python 3 in my poem making code. I was just testing it with
import language_tool
lang_tool = language_tool.LanguageTool("en-US")
text = "A sentence with a error in the Hitchhiker’s Guide tot he Galaxy"
matches = lang_tool.check(text)
print(len(matches))
but it gave me this error.
Traceback (most recent call last):
File "/home/runner/.site-packages/language_tool/__init__.py", line 548, in get_server_cmd
cmd = cache["server_cmd"]
KeyError: 'server_cmd'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/runner/.site-packages/language_tool/__init__.py", line 559, in get_jar_info
java_path, jar_path = cache["jar_info"]
KeyError: 'jar_info'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "main.py", line 10, in <module>
lang_tool = language_tool.LanguageTool("en-US")
File "/home/runner/.site-packages/language_tool/__init__.py", line 188, in __init__
self._start_server_on_free_port()
File "/home/runner/.site-packages/language_tool/__init__.py", line 323, in _start_server_on_free_port
cls._start_server()
File "/home/runner/.site-packages/language_tool/__init__.py", line 335, in _start_server
server_cmd = get_server_cmd(cls._port)
File "/home/runner/.site-packages/language_tool/__init__.py", line 550, in get_server_cmd
java_path, jar_path = get_jar_info()
File "/home/runner/.site-packages/language_tool/__init__.py", line 563, in get_jar_info
raise JavaError("can’t find Java")
language_tool.JavaError: can’t find Java
I've looked at some similar questions and I know I probably need to put something in 'Path' but I don't know what specifically to enter. Thanks for your help!
Also I'm on doing this on repl.it, not IDLE.
Note: I'm adding this as an actual answer because the question was resolved in the comments.
Your question says:
Also I'm on doing this on repl.it, not IDLE.
That means that you need to install this module and all its prerequisites into your repl.it environment, not into your local machine.
On the BitBucket link you provided, under "Prerequisites", the page says:
LanguageTool requires Java 6 or later.
So you will need to ensure Java is installed into your repl.it environment somehow. I don't know whether that is possible or not. Alternatively, you can simply install this package and all its prerequisites locally instead.
Having some issues getting a web app up and running. You can see this project running live online at yx8dxjwh.apps.lair.io but as soon as I imported it into pyCharm I am presented with a key error for the api. Please see below:
python manage.py runserver
Unhandled exception in thread started by <function check_errors.<locals>.wrapper at 0x04678078>
Traceback (most recent call last):
File "C:\Program Files (x86)\Python36-32\lib\site-packages\airtable\auth.py", line 37, in __init__
self.api_key = api_key or os.environ['AIRTABLE_API_KEY']
File "C:\Program Files (x86)\Python36-32\lib\os.py", line 669, in __getitem__
raise KeyError(key) from None
KeyError: 'AIRTABLE_API_KEY'
There is a mass of other errors too but I feel like this is the main one and could potentially solve the rest of them.
Any help would be appreciated.
You don't have the environment variable set for AIRTABLE_API_KEY. The SDK you are using leverages that environment variable by default. You can read more at: https://airtable-python-wrapper.readthedocs.io/en/master/authentication.html
And then this link can help you find your Airtable API Key if you don't have it: https://support.airtable.com/hc/en-us/articles/219046777-How-do-I-get-my-API-key-
In the following stacktrace I miss the upper frames.
Who called callback() in ioloop.py line 458?
The stacktrace comes from a unittest TestCase. All tests pass but this traceback is in the logs and reproducible.
I can't see in which test of the TestCase the exception was raised.
ERROR [25950] Exception in callback <functools.partial object at 0x5358368>
Traceback (most recent call last):
File "/home/modwork_foo_dtg/lib/python2.7/site-packages/tornado/ioloop.py", line 458, in _run_callback
callback()
File "/home/modwork_foo_dtg/lib/python2.7/site-packages/tornado/stack_context.py", line 331, in wrapped
raise_exc_info(exc)
File "/home/modwork_foo_dtg/lib/python2.7/site-packages/tornado/stack_context.py", line 302, in wrapped
ret = fn(*args, **kwargs)
File "/home/modwork_foo_dtg/src/websocketrpc/websocketrpc/client.py", line 71, in connect
self.ws = websocket_connect(self.args.url)
File "/home/modwork_foo_dtg/src/websocketrpc/websocketrpc/client.py", line 179, in websocket_connect
conn = websocket.WebSocketClientConnection(io_loop, request)
File "/home/modwork_foo_dtg/lib/python2.7/site-packages/tornado/websocket.py", line 777, in __init__
raise Exception('%s %s' % (request, request.url))
Exception: <tornado.httpclient._RequestProxy object at 0x535cb10> None
How could I use tornado to see the upper stacktrace frames?
The exception itself is not the problem.
You can use IOLoop.handle_callback_exception to print from sys.exc_info to see what specifically is breaking.
The callback was invoked by ioloop.py:458, just like it says. No outer stack frames are shown because the exception didn't escape that frame. The thing that's confusing you is that the callback goes on to re-raise an exception that was captured earlier.
In Python 2, preserving tracebacks to re-raise later is messy (it gets better in Python 3). Tornado usually does the right thing here, but there are some gaps where a traceback will get truncated. The main problem I'm aware of in current versions is that AsyncHTTPClient tends to throw away tracebacks (and there are some annoying backwards-compatibility issues with fixing this).
As a crude workaround while debugging, you can try printing traceback.format_stack just before throwing an exception (at least where it's feasible to modify the code, as you've done here to add an exception to websocket.py).
Hello I am running Python 2.5 on Windows and whenever my application gets an exception rather than seeing the debug information I get an error inside of the traceback.py file itself. Anyone know a fix for this mb a patch or replacement file.
Traceback (most recent call last):
File "C:\Python25\lib\logging\__init__.py", line 744, in emit
msg = self.format(record)
File "C:\Python25\lib\logging\__init__.py", line 630, in format
return fmt.format(record)
File "C:\Python25\lib\logging\__init__.py", line 426, in format
record.exc_text = self.formatException(record.exc_info)
File "C:\Python25\lib\logging\__init__.py", line 398, in formatException
traceback.print_exception(ei[0], ei[1], ei[2], None, sio)
File "C:\Python25\lib\traceback.py", line 126, in print_exception
lines = format_exception_only(etype, value)
File "C:\Python25\lib\traceback.py", line 176, in format_exception_only
stype = etype.__name__
AttributeError: 'NoneType' object has no attribute '__name__'
===EDIT===
Found same error in mailing list here outdated answer it seems
http://mail.python.org/pipermail/python-dev/2006-September/068975.html
Possible causes:
Calling logging.exception() when there is no active exception
Calling a logging function with exc_info=1, when there is no active exception.
Calling a logging function with exc_info=(None, None, None) to a logging function (e.g. if doing the exception logging manually).
You should not use logging.exception outside of an except block.
The exception is caused by a None exception type passed to traceback.print_exception, meaning that there is no active exception to process.
Meanwhile, the newsgroup posting you linked to indicates that it was a regression in the standard library that resulted in that particular traceback. You may want to try upgrading your Python to 2.5.1, which fixed this particular problem.