Allow temporary changes to settings

[pfmoore]

Issue Type: Feature Request

When editing a standalone file (not in a workspace) I will sometimes want to have non-standard settings. A common example is to set python.pythonPath to a specific virtualenv, needed for an individual script.

Activating the virtualenv and editing the file

venv\Scripts\activate.ps1
code myfile.py

does not result in the virtualenv being active in VS Code, if I already have VSCode open (the file is opened in the existing instance, and the path settings don't transfer over).

If I could say "set python.pythonPath to XXX" for the current session, that would be sufficient. I don't want to change my user settings, as that would be a permanent change (and I typically use temporary virtualenvs, so the environment will probably be gone before my next editing session). Even if this functionality was only available as an extension API, that would be enough as I could write my own extension to expose it.

VS Code version: Code 1.21.1 (79b44aa, 2018-03-14T14:46:47.128Z)
OS version: Windows_NT x64 6.1.7601

[roblourens]

Should this be a feature request for the Python extension, or for vscode?

If you set python.pythonPath during a session, does the Python extension pick it up immediately, or require a window reload?

I'm guessing it will require you to reload the window. If so, then this might really just be a feature request for the Python extension. But if not, I think you could have an extension that would modify that setting on activate, and restore it on deactivate.

[vscodebot]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[pfmoore]

@roblourens Sorry, this seems to have been closed because it needed more information. What exactly were you looking for?

The question about pythonPath is something I can check - but that's one specific setting and I was asking about the general case. So while it might be useful if the Python extension picked it up, it wouldn't help for other settings. Your other comment, "I think you could have an extension that would modify that setting on activate, and restore it on deactivate" sounds more promising, but you seem to be saying that rather than making a temporary setting change, I make a permanent change and revert it "on deactivation" - won't that risk the permanent setting remaining altered if the editor closes without deactivation happening (for example, if the editor crashes)?

I'm specifically asking about per-session settings, not about temporarily making changes to the settings file(s). Maybe I'm not making myself clear - I'm not 100% sure if "session" is the correct term. But basically if I have a code window open, and then I use code somefile on the command line, I'd like to be able to make changes to the settings for the somefile window (to match the environment I ran code somefile from - which may be different from the settings for the rest of the open code windows).)

[roblourens]

I understand that, but I'm not convinced that it would be generally useful. But I'll pass it on.

[sandy081]

@pfmoore Why not opening your project/folder in a Workspace ?

• Open your project in VSCode
• Open the same project in a Workspace using command Workspaces: Duplicate Workspace in New Window
• There you can have workspace settings customised only to that workspace

Let me know if this works for you?

[pfmoore]

@sandy081 Because it's not a project or folder. I have a "Scratch" directory with many individual one-file scripts in it. There's no consistent configuration for all these files, so treating the "Scratch" directory as a project or workspace is incorrect. I open a file in this directory via code myfile.py, and the directory it's in is irrelevant.

But if that file uses (for example) Pandas, I want it to run with my Data Science virtualenv active. If, on the other hand, it uses database calls, I want to run it with my DB access virtualenv. So I need to set a per-file Python path, and I can't do that.

I'm trying to move from using vim as my editor to VS Code, and this (editing single files) is a very, very common pattern of usage for me in vim. Being able to do the same in VS Code is key - if I have to continue using vim for single files, and VS Code for directory-based projects, I end up switching between two editors and that's unlikely to work as a long term solution, so I'll probably end up sticking with Vim (which would be a shame, as I'd miss out on all of the large project benefits of VS Code).

[sandy081]

@bpasero Can be this a valid use-case for file based workspaces?

[bpasero]

@sandy081 I would argue the other way around, a use-case for allowing to define settings from outside (the user level) for a specific path.

[sandy081]

Do you mean whenever a user opens this file, different user settings (associated to this file) kicks off?

[bpasero]

@sandy081 at least settings that work in the context of the editor (or can be overridden per file type) could work like this. This goes into the direction of allowing to define workspace specific settings from outside the workspace. I guess for that solution we would need to have some way of mapping settings to a path.

[sandy081]

File type specific settings would be a right solution for this.

[sandy081]

Duplicate of #35350

[vscodebot]

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for existing issues here. See also our issue reporting guidelines.

Happy Coding!

[pfmoore]

File type specific settings are emphatically not the right solution for this - I am asking for settings that will differ based on the file, even though it's the same filetype (typically Python).

Please reopen this issue - closing it as a duplicate is incorrect.

[bpasero]

@pfmoore how does being able to define settings for an absolute file path not cover that request?

[pfmoore]

@bpasero I'm confused. What I am asking for in this issue is an ability to temporarily change settings. I.e., to execute a command or edit a form that changes (say) python.pythonPath, and have that change last only for the current session, and not be persisted anywhere.

The discussion seems to have diverged into asking whether having the ability to specify settings on a per-file basis would satisfy my requirement. It would, but it would be per individual file, and not per file type, or per directory, or anything like that... And if that were the case, I don't know how the UI to configure per-file settings would work. I'm imagining something like Vim's or Emacs' modelines, settings embedded in the file, but as it's not my proposal I don't really know what's being suggested.

So my comment stands. The issue referenced (#35350) is definitely not a duplicate of this one, nor is it a solution to the problem that I have which prompted me to raise this issue. Unfortunately I don't seem to have a "re-open this issue" button available to me, otherwise I'd just reopen this - but as it stands I simply have to keep commenting here asking someone else to reopen it. If no-one can, I can open a new issue, but that will fragment the discussion which seems pointless.

[bpasero]

@pfmoore all global settings today live in a file settings.json and I could see how the following syntax could allow to define settings per file path:

{
   "<some path>": { <some settings> }
}

[pfmoore]

Agreed, but

1. As noted, I didn't ask originally for per-file settings, but temporary per-session settings.
2. That would then become invalid if I moved the file (unlike the "modeline" style of solution).

Can I suggest that if someone (remember - it wasn't me, although the feature would be useful to me and I'd happily join in the discussion) wants to discuss per-file settings, it should be on a different issue, and this issue should return to the original request, which was for temporary, per-session settings?

And can someone please re-open the issue, as it clearly isn't a duplicate of the one that was linked, and just as clearly, the discussion here is ongoing.

[sandy081]

@bpasero Coming back to initial idea, if we treat single file also as a workspace, then the settings will remain until the window is closed, unless user saves it.

@pfmoore What do you expect when an another file is opened in the same window? Do you expect the current settings also apply to that file or you expect different settings per file?

[pfmoore]

@sandy081 I hadn't really thought about that. Given that what I was suggesting was all very manual (having to set the relevant parameters every time I opened the file) it's not something I'd considered much.

If I think about how I imagined something like this being implemented, I see it as working as if I'd changed the global settings, but only in memory and once I close the instance/window, the changes I made are lost. So in that model, opening a new file in the same window would get the current settings.

I should say that in my mind, "opening a workspace/project/folder" is a very different scenario (and I have completely different expectations) than "opening a single file". And I'm talking here solely about "opening a single file" - treating VS Code as a file editor like Vim, or Notepad++, or similar. That may not be how VS Code works in practice - if so, my expectations could easily seem very odd to you (it would also mean that there's a significant documentation issue that I should flag up, but at this point I wouldn't even know how to describe that!)

[sandy081]

@pfmoore I agree that using the word workspace makes this scenario heavier and is causing confusion. It is an implementation detail that all windows (single file/empty window, folder and multi folders) are called workspaces.

I think supporting session (empty workspace / file) settings makes sense to me.

[pfmoore]

Ah, I see now. That makes sense to me. Thanks for your patience with my garbled explanations!

[masaeedu]

I'm not sure whether this falls under the same scope, but the VSCodeVim plugin needs to modify the user's status bar colors temporarily as the user enters different modes. These changes don't really need to be persisted, but nevertheless due to the lack of any other API end up constantly modifying the user's ~/.config/Code/User/settings.json, which is annoying if you version control that file.

See: VSCodeVim/Vim#2948 and the warning in the README.

[sandy081]

/duplicate

#43226 - This issue talks about supporting in memory transient settings per window session.