dvc: dvc pipeline show with ascii flag is broken on ITerm2

My 2 cents - simplify and go with less or something similar. Not sure why should we bring curses, and the whole interface is confusing, not very reliable, etc. The only question - is it possible to do it with less at all, the same experience? Especially when pipeline is pretty wide?

@drorata Indeed, didn’t know about that one. 🙂

@efiop the -S of less handles the overflow as far as I’ve tested.

@shcheklein @drorata I disagree with you, guys. We’ve been asked numerous times to introduce a UI for showing DAG and the only non-distracting way to do it is to print it or to render it in the terminal. Printing would be broken for terminals that don’t support horizontal scrolling(e.g. my default ubuntu terminal). Rendering in curses is only temporarily broken for that specific iterm2 terminal in a recent dvc version, for reasons that we will figure out and fix. Other than that, rendering allows us to present pretty much any DAG size on any terminal.

Dot option was introduced very early, but the problem with it is that you need additional actions to render it and then you would only be able to view it in a pop-up GUI window, which is distracting. But even that relies on graphviz, which doesn’t have wheels for windows(pygraphviz more precisely), making it a headache to deploy(we are not able to include it as a dependency for windows) and setup. You could use a CLI perl tool for rendering it in the terminal, but that is also not very friendly. If you feel like going with --dot, it is already there and ready to be used 🙂

About the less tool, there is no such tool on windows, to my knowledge. And even if there was, making user pipe it manually is also not very friendly.

1. I rolled back dvc to version 0.51.2 and the “plot” is not broken. Switching back to version 0.54.1 introduces the broken behavior again. Therefore, I would say that’s a proof the issue is DVC related.
2. Along DOTADIW approach, I would second @shcheklein and say that dvc should not be bothered with the rendering of the graph. To that end, yielding a dot representation is the best solution. The user can then decide how to render it.

@drorata 0.75.0 is now using pager instead of our own solution. Please feel free to try it out 🙂

@drorata Interesting. Well, something is definitely going on with the ncurses. Maybe you’ve indirectly updated it since or something and that resolved it. Let’s close this issue for now, please feel free to reopen if you run into this issue again. Thanks for the feedback! 🙂

I guess something changed somewhere — now either with TERM=linux or without it, the behavior of the show is fine.

The output of printenv | grep TERM is:

TERM_SESSION_ID=SOME-KEY
LC_TERMINAL_VERSION=3.3.4
ITERM_PROFILE=Default
TERM_PROGRAM_VERSION=3.3.4
TERM_PROGRAM=iTerm.app
LC_TERMINAL=iTerm2
COLORTERM=truecolor
TERM=xterm-256color
ITERM_SESSION_ID=SOME-OTHER-KEY

For the record: less is overflowing lines that are too long to fit into the terminal, which is fine for text and not acceptable for ascii images. Our solution deals with that.

The virtual environment I’m using is based on an environment.yml of conda. So I’m not sure pip freeze will return what you want; maybe it will because dvc is installed using pip. For the record, I rolled back dvc by simply changing the version in the pip section of the corresponding environment.yml — so the chances that some other dependencies are small.

If you still think this feedback is worthy and needed, let me know and I will be able to check it later.

I’m not sure if this is something DVC should handle, as it is working in different environments. We can choose not to use curses and go with less or another file viewer (more), or just output it to STDOUT and let the user pipe it if it is too long to read.

What do you think @iterative/engineering ?