Skip to content

Use predictable names in Remote Sessions started in VS Code have GUIDS for names and paths #13434

Open
@DonJayamanne

Description

@DonJayamanne

Today we use GUIDs

Benefits of using predictable names:

  • Inline with Jupyter Lab, Notebook and AzNb
  • Links to sessions in the above applications work
  • Single session per notebook+kernelspec

Challenges/Drawbacks

  • Users might be expecting VS Code to always create new sessions (not entirely sure why)
  • Assume we open two instances of VS Code and create two untitled files and run a cell against the same kernel.
    • What is the name of the kernel session in both cases?
    • Surely we cannot use untitled.ipynb for both,
    • We could possibly have untitled-<GUID>.ipynb for both.
    • However we still end up with GUIDs, still not perfect.
    • I do not think this is an issue.
    • If the user saves the notebook, at that point we can change the kernel session information to match the new notebook path.
    • This is what Jupyter Lab/Notebook does
  • Assume we open two different workspace folders in VS Code and create two files named sample.ipynb and run a cell against the same kernel
    • What is the name of the kernel session in both cases?
    • Surely we cannot use sample.ipynb for both,
    • In this case, we use the absolute path of the ipynb as the path for both kernel sessions.
    • This way we have a unique way to identify the kernel sessions and the notebooks they belong to.
    • The only exception is when a user connects to this same remote jupyter server with a machine having th exact same paths, thats unlikely.
  • All IW kernel sessions will have GUIDs as they are not always backed by files and there's no point keeping the *.py file as the name of the session (at least not for now).
    • We can use the *.py file name just as with the ipynb, but thats neither here nor there, as this isn't a problem today.
    • For consistently we could however use the *.py name
  • For remote Jupyter contributors like AzML, we can get the path of the remote jupyter server root directory and whether the server is localhost to the current extension host, if it is and if the workspace maps to that remote root, then all files are going to exist on the jupyter application as well, hence the paths can all be relative.

Metadata

Metadata

Assignees

Labels

debtCode quality issuesnotebook-remoteApplies to remote Jupyter Servers

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions