I'm running the most recent version of ipdb 0.10.0
and when I run the my django test suite using the nosetests plugin, once I hit a import ipdb; ipdb.set_trace() call, I can't see the prompt.
I've tried adding a '-s' parameter in the nose args, which shows the prompt, but doesn't properly capture they keyboard input in ipdb. e.g I lose input history with up and down arrow keys.
Finally, I've tried using ipdb 0.9.3 again, and it works properly.
I'm wondering if there is any way to fix this issue using the latest release of ipdb? Is there a new configuration mechanism?
As they point in the docs, this behaviour has changed, and now you have to use
ipdb.sset_trace() instead of ipdb.set_trace().
Related
Update
If I try downgrading from Pyinstaller 3.2 to 3.1 I instead get the following traceback when I try to run the executable.
I tried adding --hidden-import=collect_submodules('pkg_resources._vendor') to pyinstaller as noted here but it had no effect. Same error. This appears to be due to an issue with setuptools. I'm using 26.0.0. Downgrading to 19.3 that many sources say fixes the issue does indeed fix this issue but then I'm back to the issue I have below.
I have a python 2.7 pyqt4 project I'm trying to turn into an .exe using pyinstaller. I use:
pyinstaller --additional-hooks-rir=. --clean --win-private-assemblies pipegui.py
pipegui.py can be found on github here
I get a working executable and the app appears functional. Here is what the terminal spits while pyinstaller is freezing. However the app crashes when I run particular parts of my program. It crashes and the terminal goes in a loop continually outputting the same traceback below with "Poolworker-X" at the very top continually incrementing:
As you can see tkinter is implicated, despite the word "tkinter" appearing nowhere in my project (using pyqt4). I am making use of matplotlib though and from answers discussed here and here I have added the following to the top of pipegui.py my main script:
from Tkinter import *
import Tkinter
import FileDialog
This however seems to be a step in the wrong direction because after freezing with this (and the same flags as before) my executable wont even open and instead I get this:
Here is pyinstaller's pretty-much identical output while freezeing. Remember all I did was add those 3 import statements above. That's it.
I also tried pyinstaller --additional-hooks=. --clean --win-private-assemblies --hidden-import=Tkinter pipegui.py and it made no difference. I'm completely perplexed as to why trying to import tkinter is doing this. Will fixing this traceback lead me closer to solving the other?
I only figured out after trying all this that the only parts of my executable that are crashing are parts that make use of parmap multiprocessing. Classes that make use of matplotlib but not parmap are working fine.
So please note my question is how the first traceback can be fixed and also why are both matplotlib and tkinter popping up in the traceback despite my code where the crash occurs making use of niether?
Extra notes
I use --clean --win-private-assemblies to fix error code 14001 as per here
Repiklis provided the solution in the comments. Further note that as of January 15 2017 Pyinstaller version 3.2.1 was released. I now use this and it solves this issue along with others like this and this that I could previously only solve by using the developer version. So I highly recommend upgrading to the latest version if you haven't already.
I'm having trouble running some codes that import cx_Oracle in command line, though the same codes work in console. Is there anything else I will need to set up in order to get this to work via command line please?
Saved just one line of code "import cx_Oracle" as test.py.
Run this line in ide (Spyder), iPython Notebook => no issues
run this by opening a command line window from the same folder the .py file is saved in, and run python test.py and encounter the below:
import cx_Oracle
ImportError: DLL load failed: %1 is not a valid Win32 application.
Not sure if there is anything additional I will need to set up to run cx_Oracle via command line? Have tried all the suggestions on setting PATH, ORACLE_HOME, re-installing but could not get this to work. versions that i'm using are
Python: 2.7
cx_Oracle: cx_Oracle-5.1.3-11g.win-amd64-py2.7
instant client: 12.1.0.0
Windows: 7 Enterprise
I also found this kind of problem.
Look at "not a valid Win32 application" this sentence, so I decide to change cx_Oracle to cx_Oracle-5.1.3-11g.win-32-py2.7. Luckly, it does work.
I want to debug a Django TestCase just like I would any other Python code: Simply call pdb.set_trace() and then drop into an interactive session. When I do that, I don't see anything, as the tests are run in a different process. I'm using django-discover-runner, but my guess is that this applies to the default Django test runner.
The question:
Is it possible to drop into a pdb session while using django-discover-runner a) on every error / fail, AND/OR b) only when I call pdb.set_trace() in my test code?
Some research:
This answer explains that Django creates another process, and suggests using a call to rpdb2 debugger, a part of winpdb, but I don't want to use winpdb, I'd rather use ipdb.
This answer solves the problem for django-nose by running the test command like this: ./manage.py test -- -s, but that option's not available for django-discover-runner.
This answer shows that I can do this with ipython:
In [9]: %pdb
Automatic pdb calling has been turned ON
That seems like a potential option, but it seems a bit cumbersome to fire up ipython every time I run tests.
Finally, this answer shows that nose comes with a --pdb flag that drops into pdb on errors, which is what I want. Is my only option to switch to the django-nose test runner?
I don't see any options for this in the built-in help for django-discover-runner:
$ python manage.py help test --settings=settings.test
Usage: manage.py test [options] [appname ...]
Runs the test suite for the specified applications, or the entire site if no apps are specified.
Options:
-v VERBOSITY, --verbosity=VERBOSITY
Verbosity level; 0=minimal output, 1=normal output,
2=verbose output, 3=very verbose output
--settings=SETTINGS The Python path to a settings module, e.g.
"myproject.settings.main". If this isn't provided, the
DJANGO_SETTINGS_MODULE environment variable will be
used.
--pythonpath=PYTHONPATH
A directory to add to the Python path, e.g.
"/home/djangoprojects/myproject".
--traceback Print traceback on exception
--noinput Tells Django to NOT prompt the user for input of any
kind.
--failfast Tells Django to stop running the test suite after
first failed test.
--testrunner=TESTRUNNER
Tells Django to use specified test runner class
instead of the one specified by the TEST_RUNNER
setting.
--liveserver=LIVESERVER
Overrides the default address where the live server
(used with LiveServerTestCase) is expected to run
from. The default value is localhost:8081.
-t TOP_LEVEL, --top-level-directory=TOP_LEVEL
Top level of project for unittest discovery.
-p PATTERN, --pattern=PATTERN
The test matching pattern. Defaults to test*.py.
--version show program's version number and exit
-h, --help show this help message and exit
Django does not run tests in a separate process; the linked answer claiming it does is simply wrong. (The closest is the LiveServerTestCase for Selenium tests, which starts up a separate thread to run the development server, but this is still not a separate process, and it doesn't prevent use of pdb). You should be able to insert import pdb; pdb.set_trace() anywhere in a test (or in the tested code) and get a usable pdb prompt. I've never had trouble with this, and I just verified it again in a fresh project with Django 1.5.1 and django-discover-runner 1.0. If this isn't working for you, it's due to something else in your project, not due to Django or django-discover-runner.
Nose captures all output by default, which breaks import pdb; pdb.set_trace(). The -s option turns off output capturing. This is not necessary with the stock Django test runner or django-discover-runner, since neither of them do output-capturing to begin with.
I don't know of any equivalent to nose's --pdb option if you're using django-discover-runner. There is a django-pdb project that provides this, but a quick perusal of its code suggests to me that it wouldn't play well with django-discover-runner; its code might give you some clues towards implementing this yourself, though.
FWIW, personally I use py.test with pytest-django rather than django-discover-runner or django-nose. And even though py.test provides a --pdb option like nose, I don't use it; I often want to break earlier than the actual point of error in order to step through execution prior to the error, so I usually just insert import pytest; pytest.set_trace() (importing set_trace from pytest does the equivalent of nose's -s option; it turns off py.test's output capturing before running pdb) where I want it in the code and then remove it when I'm done. I don't find this onerous; YMMV.
Try to use ipdb instead of pdb -
import ipdb;ipdb.set_trace()
or (works in case of nose test runner)
from nose.tools import set_trace;set_trace()
I've upgraded to PyCharm 2.5 and in the meantime upgraded django-templated-email to version 0.4.3.
Now, Django unit tests do not longer work through PyCharm, as I'm getting the error ImportError: cannot import name send_templated_mail in the test console output.
When running the same test in the console, this error does not appear. I have the feeling that it has something to do with send_templated_email being part of templated_email\__init__.py (I vaguely remember a similar issue once, but cannot for the life of me remember how I fixed it).
The settings in the test dialog are:
Target: <django app name>
Custom settings: <path to dev settings>
Environment variables: PYTHONPATH: <path as set in virtualenv>
Python interpreter: <virtualenv Python interpreter>
Interpreter options: None
Working directory: <path to Django project (where manage.py resides)>
The strange thing is that the code inspection inside the IDE does not complain and loads the templated_email module correctly through from templated_email import send_templated_mail.
I'm using Windows 7, and my Django app is running inside a virtualenv (which is correctly being recognized by PyCharm).
I would suggest upgrading to version 4.5.x if you haven't already. It fixes lots of bugs and has several improvements.
Also, if you think this is a bug in PyCharm, check out their bug tracking/filing site:
https://youtrack.jetbrains.com/issues
I am trying to run unit tests in Pydev using IronPython.
When I try to run a test with Ctrl+F9 the following error message shows up in the Eclipse console window:
AttributeError: 'module' object has no attribute '_getframe'
I figured out that I have to invoke the IronPython interpreter with the '-X:Frames' argument.
Setting up the arguments in the 'Arguments' tab under 'Run->Run Configurations...' doesn't work. They seem to disappear everytime I run (Ctrl+F9) and choose another test.
Clicking 'Run->Run As->Iron Python unit-test' shows up more and more options to choose from.
Is Eclipse/Pydev creating new run configurations everytime I run a different set of tests? How can I permanently pass the '-X:Frames' argument, so my tests will run under IronPython?
(In Python the tests run without any problem.)
This shouldn't really be needed... I've just fixed the PyDev unittest runner so that it works properly (just pushed a new nightly build with that fix included -- if you're in Aptana Studio 3, a nightly is still not available, but you can patch your own version by applying the changes from the commit locally, as they're all changes in Python code: https://github.com/aptana/Pydev/commit/d5d262dbcd0c126ec0ec37e116ff79575c5dd6d8)