Hey! I’m curious what the design decisions were that led to the PDB debugger flow being deprecated in favor of the VSCode-bespoke debugger. To my eyes, a CLI-based tool will always be more flexible or usable than one that ties engineers to a specific development environment.
I don’t use VSCode as my development environment so I’m a bit concerned about this move. As it stands (given the deprecation was fairly recent) RAY_DEBUG=legacy still works fine, but there doesn’t seem to be any SLA on future compatibility with this flow going forwards. Is it expected that all workflows using the “legacy” PDB debugger may eventually break?
1 Like
Thanks for your message. We should clarify this, we are not planning to remove the CLI functionality, but we do recommend the VSCode based debugger over the CLI one, just because it is much more usable (e.g. you can easily visually inspect the variables), whereas the CLI based interface is pretty clunky to use, e.g. there is no autocompletion. So for the people who are willing to use VSCode or VSCode compatible IDEs like Cursor, it will be a much better experience.
I’m curious what programming environment you use (e.g. any particular IDE?)
1 Like
Thanks for explaining, that approach makes sense to me. I’d almost suggest removing the deprecated phrasing from the docs, as it had me worried for a bit 
I’m curious what programming environment you use (e.g. any particular IDE?)
I do much of my development via TUI, so I’m working in vim/tmux most of the time. PDB is a lot more natural for my development flow (plus it connects to vim) and needing to open VScode is rather disruptive.
1 Like