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 GitHub Comments
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