Feature request: extend scope of `"python.tensorBoard.logDirectory"` and/or support variable substitution
See original GitHub issueTLDR: "python.tensorBoard.logDirectory" is user-level only and does not seem to support variable substitution which, especially in combination, makes it very hard to use productively.
I would love to add my thoughts to https://github.com/microsoft/vscode-python/discussions/16073 or https://github.com/microsoft/vscode-python/issues/17222, but I missed them over the fall and now they are both closed.
My main argument is that not only should "python.tensorBoard.logDirectory" be a workspace setting, but also that it makes little sense as a user setting at all - should it remain a user setting, I would be surprised if many people successfully used it who are using more than one workspace. This is because the TensorBoard log dir is set
- either relatively, so it depends on the current working directory,
- or absolutely, so it has be fully defined set in the workspace code.
The problem with 1. is obvious - even the same code, run in two different workspaces, will produce two different directories. This could be taken care of by variable substition, such as "python.tensorBoard.logDirectory": "${workspaceFolder}/results/tensorboard", but I seem to be unable to pull this off:

It seems like “Visual Studio Code supports variable substitution in … some select settings” does not include this setting.
The problem with 2 is that, if your workspace code (the writer) uses a fixed TensorBoard logdir location, you have no way of ensuring (in the workspace) that the effective VS Code setting (the reader) is in sync with that. I am not sure defining a workspace-level launch configuration (for the writer) pulling in a user-level logdir location setting is very popular…
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:8 (3 by maintainers)

 Top Related Medium Post
Top Related Medium Post Top Related StackOverflow Question
Top Related StackOverflow Question
are there some verification steps that we can follow to make sure that this is resolved?
The fork from @PillarsZhang wouldn’t merge easily, so I implemented the same fix on a new fork and created pull request 20103 .
Sorry about the spam here; my experience is limited to Git