You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If we move an .ipynb file with a running kernel, it seems that the kernel's current working directory isn't changed. I think this makes sense thinking about the kernel process as a separate thing from the file location, but users can be confused.
What is our story around this workflow? Should we offer to restart a kernel to make it easier on user expectations? Should we just say this is working as designed?
The text was updated successfully, but these errors were encountered:
I don't see how you could generally maintain open file handles, etc. If
anything, introduce a UI element that indicates Something Is Not Right,
like /!\ next to/in place of the kernel indicator.
I agree that we can't really affect the kernel (I mean, who knows how to change the current working directory of random kernel XYZ?). I think the best we'd be able to do is offer to restart the kernel with the "right" working directory, or like you said, just flag the potential problem for the user.
Another things to consider - there is no guarantee the kernel is running on the same system and seeing the same files as the UI. So even restarting the kernel in that dir may not be possible.
Maybe a warning message when the notebook is moved and there is a running kernel for it would be enough. Also the message could contain that a brand new python kernel is needed and restarting it won't solve the working directory issue (if it is a feature of restarting the kernel and not a bug).
If we move an .ipynb file with a running kernel, it seems that the kernel's current working directory isn't changed. I think this makes sense thinking about the kernel process as a separate thing from the file location, but users can be confused.
What is our story around this workflow? Should we offer to restart a kernel to make it easier on user expectations? Should we just say this is working as designed?
The text was updated successfully, but these errors were encountered: