Feature Request - use a directory for profiles

[dbacher]

Use C:\ProgramData\Microsoft\Terminal, or similar, make a directory named "Profiles."
Use %APPDATA%\Microsoft\Terminal, or similar, make a directory there named "Profiles."

On startup, while reading the settings - enumerate each file in those two directories (maybe with a JSON file extension), parse it, and if it parses - add it to the profiles.

That would allow an installer from another team, for example from Visual Studio, Azure, etc. to hang a profile just by copying in a file like visual-studio-2019-cmd-tools.json or windows-platform-sdk.json.

Using separate files makes uninstall better, but this would basically be very similar to /etc/shells on Linux.

[DHowett-MSFT]

The more I think about this, the more I like the idea of dovetailing it with the dynamic profile specification from #754 😄

[dbacher]

The reason that I suggested this is there is an easy rule for many developers. The easier something is to do, the more likely they do it. Every installer can copy a file, every uninstaller can delete a file. However, modifying a JSON file? Not so much.
If I'm JASC and I'm writing 4NT (yeah, I know old school), if my installer just has to copy a file - I'm likely to do that. IF you use this approach, you might want a version tag as well.

[ffes]

And let the user define extra locations (yes, plural) , like \\server\share\path or %USERPROFILE%\OneDrive\SomePath where profiles are being searched for as well

[zadjii-msft]

I'm pretty specifically leaving out having more locations for settings files from the #1258 spec. It's definitely something I've been thinking about, but I'm afraid that adding that section would delay delivering the basic User+Default settings by a few months.

This is definitely a good idea, but lets please not rope it in with #754 :)

[DHowett-MSFT]

Just following up: we chatted o*line -- the intent was not to combine it with #754, just to say that #754 will make this infinitely easier.

[jantari]

This could be done in the Linux-way too:

Master/default settings file is:

%path%/profiles.json

But every json file inside this directory is also parsed in alphabetical order and may overwrite the settings set in the master file:

%path%/profiles.d/10-anything.json
%path%/profiles.d/20-anything.json
%path%/profiles.d/99-anything.json

This approach is familiar to most people who have used a linux-based OS before as many standard utils handle their configuration in this manner and it would work on Windows just the same.

[zadjii-msft]

For linking purposes, this seems related to #1690

[deoradh]

I really want the ability to easily backup my settings (eg, to OneDrive), and this provides a way to do so.

One suggestion:

• Include the ability to override the settings location via the command line (and being able to use this as a shortcut). That would be useful for defining sets of profiles and store them in source control or on a network share. I'm sure we've all used special command line shortcuts in the past...

[zadjii-msft]

Hey wait, isn't this exactly what we did with #1690, #7584, #7632, https://docs.microsoft.com/en-us/windows/terminal/json-fragment-extensions?

We could keep using #2933 for "let the user specify another path to load settings from". But I think the fundamental premise of

That would allow an installer from another team, for example from Visual Studio, Azure, etc. to hang a profile just by copying in a file like visual-studio-2019-cmd-tools.json or windows-platform-sdk.json.

is covered now, yea?

[zadjii-msft]

(I'm gonna answer my own question: yes, it is covered now)

[dbacher]

Sorry, had meant to confirm this a long time ago and got distracted by other things. Indeed, this is addressed by the changes you've made to the terminal client.

[zadjii-msft]

No worries, I'm persistently distracted by other things 😄