As evidenced here, I have noticed a strange new behavior in Ansible.
I have an Ansible role named "degoss" which installs Goss along with some test files to a system, executes the tests, and then removes all traces of them. I'm using a callback plugin to format the output and a custom module to invoke Goss.
When tests fail, rather than getting sensible output, in newer versions of Ansible (around 2.3 as far as I can tell), I get the following unintuitive error message and no output whatsoever from my plugin:
[WARNING]: Failure using method (v2_runner_on_failed) in callback plugin
(<ansible.plugins.callback.default.CallbackModule object at 0x7fb5e92efd50>):
'module' object has no attribute 'dumps'
Now, when I search through ansible.plugins.callback.default.CallbackModule, I don't see any invocations of dumps. When I search through ansible.plugins.callback.CallbackBase, I do see three invocations of dumps. In my own callback plugin and custom module, I have try/except blocks wrapping all of my calls to json.dumps.
What's even worse is that I can't seem to replicate the issue consistently. I can't replicate it locally, and it only appears when a task has failed. My success/failure logic is below:
succeed(module, **result) if rc == 0 else fail(
module, "Goss Tests Failed.", **result
)
My succeed/fail methods are defined as such:
def succeed(module, **kwargs):
module.exit_json(changed=False, failed=False, goss_failed=False, **kwargs)
def fail(module, message, **kwargs):
module.fail_json(msg=message, failed=True, goss_failed=True, **kwargs)
Any ideas?
Here's a guess:
ansible's callback plugin loader creates a module in ansible.plugins.callback which happens to also contain a json module. When your callback plugin imports json you get ansible.plugins.callback.json, which doesn't contain dumps. You can fix this by adding from __future__ import absolute_import to your plugin.
The reason you can't reproduce it might be that you're using Python 3 locally, which defaults to absolute imports.
In addition to the accepted answer, just want to point out that there are two files into which the import statement needs to be added.
playbooks/callback_plugins/sqs.py
and
playbooks/callback_plugins/task_timing.py
I had missed updating the task_timing.py file and so the error persisted. Pointing this out here, in case someone else also faces the same issue.
Source :edx configuration repo - diff
I am facing a similar issue as :
Robot Framework:: Imported library 'class' contains no keywords
Here, the user claims to have solved it by adding FileName.ClassName in the Settings section of .robot file. I tried the same, by adding "Library test.MyLib" but gives me the error "Importing test library 'test.MyLib' failed: Module 'test' does not contain 'MyLib'". However, when I remove and revert back to just "Library test", I get a warning as "[ WARN ] Imported library 'test' contains no keywords" and an error as "No keyword with name 'hello' found." My code is as follows :
test.py
class MyLib(object):
__all__ = ['hello']
def __init__(self):
name = "Wrath"
def hello(self, *args):
name = self.args[0]
print "Hello "+name
test.robot
*** Settings ***
Documentation Suite description
Library test
*** Test Cases ***
Test title
[Tags] DEBUG
hello Sloth
*** Keywords ***
It would be really helpful if I'm advised on the above issue. Have tried out official Robot Framework documentation and the few examples on the web, but seems like I'm doing right. But I have a feeling that I'm probably missing out some minor but crucial thing up there. Precisely, the Keyword section maybe?
From the symptoms you describe, it sounds like you have another "test.py" file that robot is loading, instead of the keyword file you think it's loading.
A way to determine that is to generate a syslog, which will tell you which file is actually being imported.
The other thing you can try is to rename your library to something other than "test.py", and then modify your import statement accordingly. If it works with another name, that is proof that you have more than one "test.py" in your environment.
Okay, my bad. I got a little confused after reading the official documentation of Robot Framework. After many repeated runs of trial and error I found out what I was doing wrong. I got it running finally and here are my observations :
First and foremost thing, I separated the libraries and formed a clean directory structure for each program I was executing.
Secondly, made sure there are exactly 2 whitespaces (i.e, ' ') between the keyword (I'm working on static API) and argument in the .robot file.
Renamed the class in the library file "MyLibrary.py" to anything other than "MyLibrary", say "MyClass". This could help avoid some confusion for a beginner like me. Then, include the class as "Library MyLibrary.MyClass" in "Settings" header of .robot file.
If you make sure of the above, your test suite should execute smoothly, provided you don't have any syntactical or logical errors in your program and the framework environment is proper.
After following the instructions given on this site: https://sourceware.org/gdb/wiki/STLSupport
GDB is still unable to print the contents of stl containers like vectors, other than printing out a huge amount of useless information. When GDB loads, I also get the following errors, which I think are related to the Python that I put into ~/.gdbinit
Traceback (most recent call last):
File "<string>", line 4, in <module>
File "/Users/mayankp/gdb_printers/python/libstdcxx/v6/printers.py", line 1247, in register_libstdcxx_printers
gdb.printing.register_pretty_printer(obj, libstdcxx_printer)
File "/usr/local/share/gdb/python/gdb/printing.py", line 146, in register_pretty_printer
printer.name)
RuntimeError: pretty-printer already registered: libstdc++-v6
/Users/mayankp/.gdbinit:6: Error in sourced command file:
Error while executing Python code.
When GDB loads, I also get the following errors...
It looks like instructions you followed on https://sourceware.org/gdb/wiki/STLSupport are invalid now. If you look at svn log you will see that registering of pretty printers was added in __init__.py recently:
------------------------------------------------------------------------
r215726 | redi | 2014-09-30 18:33:27 +0300 (Вт., 30 сент. 2014) | 4 lines
2014-09-30 Siva Chandra Reddy <sivachandra#google.com>
* python/hook.in: Only import libstdcxx.v6.
* python/libstdcxx/v6/__init__.py: Load printers and xmethods.
------------------------------------------------------------------------
And therefore second registration throws error. You can remove it or comment out:
#register_libstdcxx_printers (None)
GDB is still unable to print the contents of stl containers
You have probably mismatched pretty printers with your gcc. See https://stackoverflow.com/a/9108404/72178 for details.
From your traceback it seems that the register_libstdcxx_printers() call is failing because there already is such a pretty printer registered. To avoid that, you can wrap it in a try..except to make sure instructions in .gdbinit don't interfere with the launch of GDB if they fail:
python
import sys
sys.path.insert(0, '/home/user/gdb_printers/python')
from libstdcxx.v6.printers import register_libstdcxx_printers
try:
register_libstdcxx_printers(None)
except:
pass
end
(Note: You should usually never use a bare except statement without qualifying the type of exceptions you want to catch. This is a special case though, in startup configuration files like .gdbinit, .pdbrc or your PYTHONSTARTUP file you'll probably want to write defensive code like that).
But chances are this will only get rid of the ugly traceback for you, and printing of STL vectors still wont work. Because it seems there is already a pretty printer registered from somewhere else.
Make sure the path /home/user/gdb_printers/python actually matches the path where you checked out the module mentioned in the STLSupport docs.
Question is simple, I have two lines in my Python script:
# pylint: disable=C0301, W0212
#!/usr/bin/env python
Both of them have to be on the first line otherwise they will not work.
How do you suggest I resolve this?
The following goes on the first line:
#!/usr/bin/env python
Pylint messages can go on any line. As the documentation says:
Is it possible to locally disable a particular message? This may be done by adding “#pylint: disable=W0123,E4567” at the desired block level or at the end of the desired line of code
So the message needs to be at the same block level (so the second line would work as well as that's the same block / scope). Furthermore the documentation says:
Is there a way to disable a message for a particular module only? Yes, you can disable or enable (globally disabled) messages at the module level by adding the corresponding option in a comment at the top of the file:
So it doesn't say: "first line of the file"; as long as the disable message is at the top of the file then it's fine.
Pylint disable comments do not need to be in the top line to work.
I'm running lint as follows:
$ python -m pylint.lint m2test.py
with this code:
import M2Crypto
def f():
M2Crypto.RSA.new_pub_key("").as_pem(cipher=None).split("\n")
The lint output ends with:
Exception AttributeError: '_shutdown' in <module 'threading' from '/usr/lib/python2.7/site-packages/M2Crypto-0.21.1-py2.7-linux-x86_64.egg/M2Crypto/threading.pyc'> ignored
This code works fine when run (the above is actually a minimal test case; but the full version does work). The exception is ignored, but Bitten considers this a failure, so stops on this step.
I've tried adding 'M2Crypto.threading.init()'/'M2Crypto.threading.cleanup()' around the definition of the function, but that didn't fix the problem.
How can I prevent this problem from occurring?
I'm using M2Crypto 0.21.1, pylint 0.24 and Python 2.7 (also tried 2.7.2) on Debian Lenny x86_64.
The exception that you are seeing is caused by a bug in the astng package (presumably “Abstract Syntax Tree, Next Generation”?) which is a toolkit on which pylint depends, written by the same people. I should note in passing that I always encourage people to use pyflakes instead of pylint when possible, because it is quick, simple, fast, and predictable, whereas pylint tries to do several kinds of deep magic that are not only slow but that can get it into exactly this kind of trouble. :)
Here are the two packages on PyPI:
http://pypi.python.org/pypi/pylint
http://pypi.python.org/pypi/astng
And note that this problem had to be, necessarily, a bug in pylint and not in your code, because pylint does not run your code in order to produce its report — imagine the havoc that could be wreaked if it did (since code being linted might delete files, etcetera)! Since your code does not get run, no amount of caution, like protecting your call with threading init() or cleanup() functions, could possibly have prevented this error — unless the code snippets happened, for other reasons, to alter the behavior we are about to investigate.
So, on to your actual exception.
I had never actually heard of _shutdown before! A quick search of the Python standard library showed its definition in threading.py but not a call of the function from anywhere; only by searching the Python C source code did I discover where in pythonrun.c, during interpreter shutdown, the function is actually called:
static void
wait_for_thread_shutdown(void)
{
...
PyObject *threading = PyMapping_GetItemString(tstate->interp->modules,
"threading");
if (threading == NULL) {
/* threading not imported */
PyErr_Clear();
return;
}
result = PyObject_CallMethod(threading, "_shutdown", "");
if (result == NULL) {
PyErr_WriteUnraisable(threading);
}
...
}
Apparently it is some sort of cleanup function that the threading Standard Library module requires, and they have special-cased the Python interpreter itself to make sure that it gets called.
As you can see from the code above, Python quietly and without complaint handles the case where the threading module never gets imported during a program's run. But if threading does get imported, and still exists at shutdown time, then the interpreter looks inside for a _shutdown function and goes so far as to print an error message — and then return a non-zero exit status, the cause of your problems — if it cannot call it.
So we have to discover why the threading module exists but has no _shutdown method at the moment when pylint is done examining your program and Python is exiting. Some instrumention is called for. Can we print out what the module looks like as pylint exits? We can! The pylint/lint.py module, in its last few lines, runs its “main program” by instantiating a Run class it has defined:
if __name__ == '__main__':
Run(sys.argv[1:])
So I opened lint.py in my editor — one of the magnificent things about having each little project installed in a Python Virual Environment is that I can jump in and edit third-party code for quick experiments — and added the following print statement down at the bottom of the Run class's __init__() method:
sys.path.pop(0)
print "*****", sys.modules['threading'].__file__ # added by me!
if exit:
sys.exit(self.linter.msg_status)
I re-ran the command:
python -m pylint.lint m2test.py
And out came the __file__ string of the threading module:
***** /home/brandon/venv/lib/python2.7/site-packages/M2Crypto/threading.pyc
Well, look at that.
This is the problem!
According to this path, there actually exists an M2Crypto/threading.py module that, under all normal circumstances, should just be called M2Crypto.threading, and therefore sit in the sys.modules dictionary under the name:
sys.modules['M2Crypto.threading']
But somehow that file is also getting loaded as the main Python threading module, shadowing the official threading module that sits in the Standard Library. Because of this, the Python exit logic is quite correctly complaining that the Standard Library _shutdown() function is missing.
How could this happen? Top-level modules can only appear in paths that are listed explicitly in sys.path, not in sub-directories beneath them. This leads to a new question: is there any point during the pylint run that the …/M2Crypto/ directory itself is getting put on sys.path as though it contained top-level modules? Let's see!
We need more instrumentation: we need to have Python tell us the moment that a directory with M2Crypto in the name appears in sys.path. It will really slow things down, but let's add a trace function to pylint's __init__.py — because that is the first module that gets imported when you run -m pylint.lint — that will write an output file telling us, for every line of code executed, whether sys.path has any bad values in it:
def install_tracer():
import sys
output = open('mytracer.out', 'w')
def mytracer(frame, event, arg):
broken = any(p.endswith('M2Crypto') for p in sys.path)
output.write('{} {}:{} {}\n'.format(
broken, frame.f_code.co_filename, frame.f_lineno, event))
return mytracer
sys.settrace(mytracer)
install_tracer()
del install_tracer
Note how careful I am here: I define only one name in the module's namespace, and then carefully delete it to clean up after myself before I let pylint continue loading! And all of the resources that the trace function itself needs — namely, the sys module and the output open file — are available in the install_tracer() closure so that, from the outside, pylint looks exactly the same as always. Just in case anyone tries to introspect it, like pylint might!
This generates a file mytracer.out of about 800k lines, that each look something like this:
False /home/brandon/venv/lib/python2.7/posixpath.py:118 call
The False says that sys.path looks clean, the filename and line number are the line of code being executed, and call indicates what stage of execution the interpreter is in.
So does sys.path ever get poisoned? Let's look at just the first True or False on each line, and see how many successive lines start with each value:
$ awk '{print$1}' mytracer.out | uniq -c
607997 False
3173 True
4558 False
33217 True
4304 False
41699 True
2953 False
110503 True
52575 False
Wow! That's a problem! For runs of several thousand lines at a time, our test case is True, which means that the interpreter is running with …/M2Crypto/ — or some variant of a pathname with M2Crypto in it — on the path, where it should not be; only the directory that contains …/M2Crypto should ever be on the path. Looking for the first False to True transition in the file, I see this:
False /home/brandon/venv/lib/python2.7/site-packages/logilab/astng/builder.py:132 line
False /home/brandon/venv/lib/python2.7/posixpath.py:118 call
...
False /home/brandon/venv/lib/python2.7/posixpath.py:124 line
False /home/brandon/venv/lib/python2.7/posixpath.py:124 return
True /home/brandon/venv/lib/python2.7/site-packages/logilab/astng/builder.py:133 line
And looking at lines 132 and 133 in the builder.py file reveals our culprit:
130 # build astng representation
131 try:
132 sys.path.insert(0, dirname(path)) # XXX (syt) iirk
133 node = self.string_build(data, modname, path)
134 finally:
135 sys.path.pop(0)
Note the comment, which is part of the original code, not an addition of my own! Obviously, XXX (syt) iirk is an exclamation in this programmer's strange native language for the phrase, “put this module's parent directory on sys.path so that pylint will break mysteriously every time someone forces pylint to introspect a package with a threading sub-module.” It is, obviously, a very compact native language. :)
If you adjust the tracing module to watch sys.modules for the actual import of threading — an exercise I will leave to the reader — you will see that it happens when SocketServer, which is imported by some other Standard Library module during the analysis, in turn tries to innocently import threading.
So let us review what is happening:
pylint is dangerous magic.
As part of its magic, if it sees you import foo, then it runs off trying to find foo.py on disk, to parse it, and to predict whether you are loading valid or invalid names from its namespace.
[See my comment, below.] Because you call .split() on the return value of RSA.as_pem(), pylint tries to introspect the as_pem() method, which in turn uses the M2Crypto.BIO module, which in turn makes calls that induce pylint to import threading.
As part of loading any module foo.py, pylint throws the directory containing foo.py on sys.path, even if that directory is inside a package, and therefore gives modules in that directory the privilege of shadowing Standard Library modules of the same name during its analysis.
When Python exits, it is upset that the M2Crypto.threading library is sitting where threading belongs, because it wants to run the _shutdown() method of threading.
You should report this as a bug to the pylint / astng folks at logilab.org. Tell them I sent you.
If you decide to keep using pylint after it has done this to you, then there seem to be two solutions in this case: either don't inspect code that calls M2Crypto, or import threading during the pylint import process — by sticking import threading into the pylint/__init__.py, for example — so that the module gets the chance to grab the sys.modules['threading'] slot before pylint gets all excited and tries to let M2Crypto/threading.py grab the slot instead.
In conclusion, I think the author of astng says it best: XXX (syt) iirk. Indeed.
Many thanks to Brandon Craig Rhodes for having tracing this down and for such a detailed post.
I've removed the offending line from astng, code available from the hg repository until logilab-astng 0.23.0 is out. And I can confirm this fixes the OP's pb.
This looks more like a hack but I think it works. Copying the result of "as_pem()" and splitting it.
import M2Crypto
def f():
M2Crypto.RSA.new_pub_key("").as_pem(cipher=None)[:].split("\n")
I'm using Python 2.6.7, M2Crypto 0.21.1, pylint 0.23
I was unable to reproduce (pylint 0.24 and M2Crypto 0.21.1 on Ubuntu 11.04 64bit) but two suggestions:
Explicitly initialize threading:
import M2Crypto
def f():
M2Crypto.threading.init()
M2Crypto.RSA.new_pub_key("").as_pem(cipher=None).split("\n")
M2Crypto.threading.cleanup()
Or recompile without threading:
m2crypto = Extension(name = 'M2Crypto.__m2crypto',
sources = ['SWIG/_m2crypto.i'],
extra_compile_args = ['-DTHREADING'],
#extra_link_args = ['-Wl,-search_paths_first'], # Uncomment to build Universal Mac binaries
)