wavetermdev
Improved Subshell Support
An opened subshell is currently treated as a running command by the UI. This negates all of Wave UI advancements, like the command blocks. The whole user experience is just one giant cell with a subshell running in it until it's closed.
A good example of usage is a Poetry shell. Poetry, a Python dependency manager, allows you to open a subshell with a dedicated Python virtual env for your project to better manage your dependencies. So you open a Poetry shell and do all your subsequent work in it, like run unit tests, or even open VS Code from within it, because that will ensure your VS Code debugger automatically uses the correct environment etc.
Possible solutions:
- Set a subshell for a tab or workspace in a dedicated UI (sort of like the "connect" menu works now)
or even better,
- When a subshell is opened in one of the blocks, ask the user if it this should now apply to all new block executions in the current tab or workspace, or run the subshell like it does currently, in one block. If the former is chosen, all new code block executions should run in this new subshell. A UI should indicate that this is the case.
It hurts me to link to this, but it's an example that it's possible to do better.
thanks for submitting. do you have a specific use case for the subshell (so we can make sure we support it)? Wave does support different environments within a tab by using "cr". not sure that solves your issue, but it is possible for us to extend that functionality so it might cover what you need.
A good example for my use case is Poetry or docker exec. For poetry, if our project uses Python in any way (even just some script on top), we use poetry to manage dependencies. It's great because you just do poetry shell and then you don't have to worry about using correct versions of Python or packages, it happens automatically. Usually I would open like 3 tabs in iTerm for a project, open Poetry shell in them and I know I won't have to worry about it. AFAIK this is quite typical usage.
docker exec probably doesn't need an introduction.
I think it might be possible to achieve both with your cr tool, but it's definitely a worse user experience than executing a subshell and it working automatically :)
