Have a problem with show --ascii
:
$ dvc pipeline show --ascii evaluate.dvc
ERROR: unexpected error - setupterm: could not find terminal
Hi @Abrosimov-a-a ! Thanks for reporting the issue! Could you please run
dvc pipeline show --ascii evaluate.dvc -v
and provide full log for it?
After that, could you please try this workaround
dvc pipeline show --ascii evaluate.dvc | less -S
?
Hi @efiop ! Thanks for helping!
dvc pipeline show --ascii evaluate.dvc -v
Traceback (most recent call last):
File "dvc/main.py", line 44, in main
File "dvc/command/pipeline.py", line 140, in run
File "dvc/command/pipeline.py", line 91, in _show_ascii
File "dvc/dagascii.py", line 372, in draw
File "dvc/dagascii.py", line 66, in draw
File "site-packages/asciimatics/screen.py", line 1337, in wrapper
File "site-packages/asciimatics/screen.py", line 1292, in open
File "curses/__init__.py", line 30, in initscr
_curses.error: setupterm: could not find terminal
dvc pipeline show --ascii evaluate.dvc | less -S
work is good.
dvc pipeline show --ascii evaluate.dvc
working correctly only with the TERM=linux
environment variable.
It is an ncurses error, I think.
@Abrosimov-a-a Thanks for the investigation! Might be related to https://github.com/iterative/dvc/issues/2420 as well. What ncurses version are you using, btw? I guess, it is the one included with your python, right? Which python version are you using?
My Python version is 3.7.3 with built-in curses version 2.2. I find some information about that. In the next weekend I will try to patch the DVC or report about this bug to the ncurses dev team.
@Abrosimov-a-a I have the same ncurses version. Looks like it is TERM=xterm-256color
that is to blame. Ncurses seems to have it mentioned quite a few times in https://invisible-island.net/ncurses/ncurses.faq.html , though I can't put my finger on anything specific just yet. Also, I can't really reproduce the issue even on iterm2 where TERM is xterm-256color by default. So there is something else to it.
Bug is't present in pip version of DVC (0.66.11).
I looked at the source of the deb package. You embed all the dependencies in the package. This is a very bad idea! You include your own Python. In Linux! WTF? I don鈥檛 have so much time and desire to figure it out. I assume that the bug appears due to the fact that you are using the Python version without applying Debian patches.
I don鈥檛 like it so much that I鈥檓 ready to organize package assembly for you. But this does not concern this issue.
@Abrosimov-a-a Ah, I forgot to ask which package you are using. So deb is affected for you, but pip is not, right?
Yes. Deb is affected, but whl is working correctly.
@Abrosimov-a-a Oh, got it. Interesting. So probably the machine we build our deb on has an old ncurses, that is causing this. Thanks for the investigation! 馃檹
@Abrosimov-a-a Btw, take a look at https://github.com/iterative/dvc/issues/2807 , maybe it is better to implement that instead of bothering with repackaging stuff, even though the repackaging is useful by itself anyway 馃檪
@Abrosimov-a-a One more question, why deb was your first choice when installing dvc, why not pip or conda? Related to https://github.com/iterative/dvc/issues/2760
@efiop
instead of bothering with repackaging stuff
It's not a Linux way. It's not a Python way. There is no way for appanding to the any Linux distribs.
why deb was your first choice when installing dvc
Because DVC is a system wired tool, not code dependency.
@Abrosimov-a-a Are you still able to reproduce that issue? Should've been fixed by #2807 . Closing for now, please ping us if the issue still persists.
Most helpful comment
@efiop
It's not a Linux way. It's not a Python way. There is no way for appanding to the any Linux distribs.
Because DVC is a system wired tool, not code dependency.