nir0s / backtrace Goto Github PK

pypi tar.gz package is uninstallable, the error is No such file or directory: 'LICENSE'. The file is, indeed, missing from the archive.

The wheel installs fine though.

Thank you for developing this package. I am glad to have found it.
My issue is that I wasn't able to use it, just out of the box.

I just ran $ python manage.py migrate | backtrace but I got an error that says:

django.db.utils.OperationalError: no such table: accounts_user
No Traceback detected. Make sure you pipe stderr to backtrace correctly.

Let me know if I can provide further details.
Cheers.

Here is my attempt at improved tracebacks:

Google Colab standard backtrace	Niceback enabled

https://github.com/Tronic/niceback

The issue backtrace requires colorlama==0.3.7 is fixed but not published. My package is dependent on backtrace and it prints the version conflict error when installing. Please consider publishing new version.

Thank you so much for this utility it helps me a lot! It appears that there's some problem with parsing. See the original traceback (Figure 1) and the parsed traceback (Figure 2). The black squares cover the same file path. The reason why I feel there might be problems is that the yellow bold text after the arrow appears not very consistent with each other. It should be respectively "in main", "in run_divg_...", etc., instead of "in main", "control=2)", etc., from my point of view. Thanks!

Figure 1:

Figure 2:

When running backtrace without providing it with any input from stdin, backtrace will try to read it but hang because nothing goes through. Instead, it should be first test to see that stdin isn't empty and exit if it is.

I often want to view stdout as well, and it would be nice if backtrace let that be printed as is.

The output of an exception that isn't parsed well:

Traceback (most recent call last):
  File "/home/nir0s/repos/nir0s/backtrace/test2.py", line 4, in moose_bites_kan_be_pretty_nasti
    with open(filename) as f:
FileNotFoundError: [Errno 2] No such file or directory: 'certainly_a_non_existing_moose'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "test.py", line 123, in <module>
    i = Moose()
  File "test.py", line 25, in __init__
    self.a_moose_once_bit_my_sister()
  File "test.py", line 28, in a_moose_once_bit_my_sister
    _mynd_you()
  File "test.py", line 118, in _mynd_you
    test2.moose_bites_kan_be_pretty_nasti()
  File "/home/nir0s/repos/nir0s/backtrace/test2.py", line 10, in moose_bites_kan_be_pretty_nasti
    moose_func(ex)
  File "/home/nir0s/repos/nir0s/backtrace/test2.py", line 14, in moose_func
    raise raise_moose(ex)
  File "/home/nir0s/repos/nir0s/backtrace/test2.py", line 18, in raise_moose
    raise MooseError(ex)
test2.MooseError: [Errno 2] No such file or directory: 'certainly_a_non_existing_moose'

The colorama dependency is specified as colorama==0.3.7. Is there a reason for such strictness or may I just override it and use it with, e.g., 0.3.9?

It would be amazing to see local variables in each frame of the traceback. It really helps debugging!

In python3, running the following will result in backtrace not identifying a traceback:

try:
    raise Exception
except Exception:
    _, __, tb = sys.exc_info()
    raise Exception(tb)

$ python test.py 2>&1 | backtrace

I don't want colorama autoreset=True. Why are you pushing this on me?
You should call colorama.init() if you have to, but reset colors as you require.
I should be able to set autoreset as I prefer, your stuff should work either way.