Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for roaming settings.json or storing it elsewhere #2933

Open
patriksvensson opened this issue Sep 27, 2019 · 33 comments
Open

Add support for roaming settings.json or storing it elsewhere #2933

patriksvensson opened this issue Sep 27, 2019 · 33 comments
Labels
Area-Settings Help Wanted Issue-Feature Product-Terminal
Milestone

Comments

@patriksvensson
Copy link

@patriksvensson patriksvensson commented Sep 27, 2019

Description of the new feature/enhancement

I have three different computers that I use for work. I keep my PowerShell profile in a GitHub repository and dot source it in my local PowerShell profile. That way I will only need to do a git pull on my profile repository to get all changes propagated on each computer.

It would be great if I could do something similar with my Windows Terminal settings by simply stating in my local settings.json file that the "real" settings could be found somewhere else.

(It could even be that the loaded profile acts like a base for the settings on the computer so things could be overridden, but that is a completely different issue that remains to be opened)

I'm aware that I might have overlooked something here, but would love to start a discussion about this since I suspect that I'm not the only one with this "problem".

Proposed technical implementation details (optional)

{
    "$schema": "https://aka.ms/terminal-profiles-schema",
    "globals": {
        "loadProfileFrom": "C:/Source/git/profiles/terminal_profile.json"
    }
@patriksvensson patriksvensson added the Issue-Feature label Sep 27, 2019
@msftbot msftbot bot added Needs-Triage Needs-Tag-Fix labels Sep 27, 2019
@carlos-zamora carlos-zamora added Area-Settings Product-Terminal and removed Needs-Tag-Fix labels Sep 27, 2019
@brandonh-msft
Copy link

@brandonh-msft brandonh-msft commented Sep 30, 2019

any reason we can't just use the UWP Roaming data store?
https://docs.microsoft.com/en-us/windows/uwp/design/app-settings/store-and-retrieve-app-data#roaming-data

I know this isn't a true UWP app, but Centennials can still use the UWP APIs, right?

@DHowett-MSFT
Copy link
Contributor

@DHowett-MSFT DHowett-MSFT commented Sep 30, 2019

We actually used to roam your settings using those exact APIs, but it caused us way more headache than it was worth. There’s a couple things we need to nail before we consider turning roaming back on.

@brandonh-msft
Copy link

@brandonh-msft brandonh-msft commented Sep 30, 2019

yeah was just coming back to edit.

looks like per here: https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-enhance
and here: https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-supported-api

we can't simply use RoamingFolder as I'd hoped? In lieu of this, then, @patriksvensson's approach is probably the best we'll get and users - well I, for one - could simply point at a OneDrive (or similar) location.

@zadjii-msft
Copy link
Member

@zadjii-msft zadjii-msft commented Sep 30, 2019

I'm more using this issue as a tracker for "add a way to import settings from other paths" than a "re-enable settings roaming". Using RoamingState for storing the settings was a pain. However, I think that we all agree adding support for importing settings from another location is a good idea, but one that needs careful thought and preferably a spec to go with it.

This is even a scenario referenced in the original cascading settings spec, as something we could consider in the future.

#1770 was the original bug tracking disabling roaming settings. Note the pile of other issues that were dupe'd to it.


April 15, 2022 edit:

I'm sneaking in here to add some notes about what re-enabling this again might look like. I'm reusing this old comment to avoid pinging folks till I have a plan.

What went wrong the first time

Plan for this time

  • When we load the settings, look first in roamingstate, then fall back to localstate.
  • Write the settings back out to roaming state.
  • Should state.json's get written to roaming? Quite surely not.
    • ⚠️ if they've deleted a WSL profile from their settings, then the file gets roamed, and that distro is on the new machine (where there's not yet a state.json), the profile will come back to their settings file. It'll also then get roamed BACK to the machine that had originally deleted it.
  • If we load from roaming, and see that there's a dynamic profile in there that we don't have locally, prompt the user to install it.
    • How does this combine with the "whoops we couldn't find your default profile" warning?
    • Make it an infobar maybe?
    • Can we easily just winget install {pwsh}, winget install {pwsh preview} in a new tab? that would be crisp
  • What do we do about fragments?
  • What how do we deal with symlinks? Do we need to do anything?
    • I suppose, if a user today has their localstate symlinked elsewhere, then they want the file to live elsewhere. They want it written to the elsewhere.
    • ⚠️ If we add a new symlink to the roamingstate folder, will it roam the contents of the link target to the roamingstate on a new machine?
    • If they add a symlink in roaming state, that'll probably get blown away if the settings roam back, yea?
      • It's probably okay to let them just symlink in LocalState though, and that'll prevent us from loading the roamed file.
    • Is just not roaming settings for folks with a symlink a reasonable UX? "I've taken things into my own hands"
  • more....

Other things to keep in mind

  • "Store settings elsewhere" - like, load additional files into the settings. IIRC my original imagination for this was something like "include": [ "{path-to-file.json}" ] as a global setting that would load cascade additional paths.
    • This was originally #2303, but we thought fragments sufficiently addressed that. It might not have.
    • Surely, the paths for additionally included settings files won't work on the machine they were roamed to. May be okay to silently ignore those failures though.
  • #4566
    • in general I hate this. Loading settings based on the value of an env var that's set seems fragile or prone to not working as expected, esp. given the number of issues we've had with env vars in the past.
  • #6687
    • Much less fragile than the above, but still comes with issues. We'd have to make sure that the window that's started with those settings then only writes back to that file?
  • Are there other roaming types that we might want to deal with? If the user has multiple MSA's logged in, is that an issue? Something like the "merge" mentioned here
  • #12807
    • We'll need to document this, cause it'll never work.
    • This will obviously be annoying.

@patriksvensson
Copy link
Author

@patriksvensson patriksvensson commented Sep 30, 2019

@zadjii-msft What's the process for creating a spec for something? Do you have an RFC-process or similar?

@zadjii-msft
Copy link
Member

@zadjii-msft zadjii-msft commented Sep 30, 2019

@patriksvensson We don't have an official "RFC" process, but we do have a semi-formal spec review process. This helps us ensure the entire team is on-board with more complicated features, and for scenarios like this one, some of the more complicated edge cases have been thought out. I'd refer to the following:

@zadjii-msft zadjii-msft added this to Spec Needed ❓ in Specification Tracker via automation Sep 30, 2019
@zadjii-msft zadjii-msft added this to the Terminal Backlog milestone Sep 30, 2019
@patriksvensson
Copy link
Author

@patriksvensson patriksvensson commented Sep 30, 2019

@zadjii-msft Would it help if I (or someone else) drafted up a spec to get the ball rolling?

@DHowett-MSFT DHowett-MSFT added Help Wanted and removed Needs-Triage labels Sep 30, 2019
@zadjii-msft
Copy link
Member

@zadjii-msft zadjii-msft commented Sep 30, 2019

I think that would be very helpful :)

@jpetkau
Copy link

@jpetkau jpetkau commented Nov 11, 2019

As a workaround for this, it's possible to make profiles.json a symlink to a shared settings file in Roaming or OneDrive or Dropbox or whatever.

This mostly works, except terminal doesn't notice changes to the actual file. It only watches the symlink. So hot-reloading of changes doesn't work.

Of course roaming just magically working would be better.

@DHowett-MSFT DHowett-MSFT changed the title Add support for roaming settings.json Add support for roaming settings.json or storing it elsewhere Dec 9, 2019
@chwarr
Copy link
Member

@chwarr chwarr commented Mar 9, 2020

There's a related issue in this space, #4566 "Consider adding a WT_PROFILE env var pointing to settings file for 1.0 release".

It proposes setting the environment variable WT_PROFILE to the path of the user's settings file. Copying a comment that I made on that here:

My expectation of a variable like WT_PROFILE would be that I could [also] use it to change where Windows Terminal reads user settings from. ...

Based on how other, similar software works, I think it would make sense if Windows Terminal only read this environment variable at process start up and then monitored the path for changes. It would also be reasonable for Windows Terminal to detect changes to the environment "template" by handling WM_SETTINGCHANGE notifications. (Though, there are some subtle details to consider about when changes are applied. Lots of thoughts in #1125, "Feature Request: Terminal should listen for the WM_SETTINGCHANGE for environment variable updates".)

@patriksvensson
Copy link
Author

@patriksvensson patriksvensson commented Mar 9, 2020

If anyone is interested in an interim solution to this, I've written some instructions here: https://www.patriksvensson.se/2019/12/roaming-profiles-with-windows-terminal

@DavidGamba
Copy link

@DavidGamba DavidGamba commented Apr 27, 2020

If the file watcher that monitors profiles.json can detect a symlink and watch the target instead many users would easily backup their config in multiple ways and still get the full benefits of hot reload of the config.

1 similar comment
@DavidGamba
Copy link

@DavidGamba DavidGamba commented Apr 27, 2020

If the file watcher that monitors profiles.json can detect a symlink and watch the target instead many users would easily backup their config in multiple ways and still get the full benefits of hot reload of the config.

@zadjii-msft
Copy link
Member

@zadjii-msft zadjii-msft commented Apr 29, 2020

From @MartinSGill in #5638

Proposed technical implementation details (optional)

The common linux practice of using a settings.d style folder and loading all files in that folder seems like a good approach to me.

* Settings.json defines an "include" directory (environment variables permitted)

* Settings loads all files in that folder in alphabetical order.

* Settings adds/overrides settings based on loaded files.

* Additional files would all have the same structure/schema as the default settings.json

* [Extra Credit] Support multiple folders, allow shared/user settings.

@Cortana-117
Copy link

@Cortana-117 Cortana-117 commented Mar 12, 2021

Add Cloud sync support with our Microsoft account.

@thernstig
Copy link

@thernstig thernstig commented Apr 6, 2021

If anything, I think to be best-in-class it should follow how VS Code does this. FIrst let a user have User settings as well as Machine settings (which takes precedence over User settings when on a particular machine, but both should be synced still for backup purposes). Then add different Authentication providers that one can connect to, to sync the settings automatically. Examples of such providers: Github account, Microsoft account.

Syncing is then done seamlessly in the background when logged in. You can get history of syncs. Etc.

@Falven
Copy link

@Falven Falven commented May 20, 2021

If anything, I think to be best-in-class it should follow how VS Code does this. FIrst let a user have User settings as well as Machine settings (which takes precedence over User settings when on a particular machine, but both should be synced still for backup purposes). Then add different Authentication providers that one can connect to, to sync the settings automatically. Examples of such providers: Github account, Microsoft account.

Syncing is then done seamlessly in the background when logged in. You can get history of syncs. Etc.

Any ideas if this is being implemented? I see the thread being closed and reopened multiple times but no work item linked or anything.

@zadjii-msft
Copy link
Member

@zadjii-msft zadjii-msft commented May 20, 2021

I see the thread being closed and reopened multiple times but no work item linked or anything.

???

This thread has remained open since it was first filed. Maybe you posted on the wrong thread?

We're not working on this currently, nor do we have plans to do this in the 2.0 timeframe. The original roaming settings were a pain, but easy to implement. The VsCode method of roaming though sounds like quite a bit more work. Better for sure, but not something we're about to get to any time soon.

@Falven
Copy link

@Falven Falven commented May 20, 2021

We're not working on this currently, nor do we have plans to do this in the 2.0 timeframe. The original roaming settings were a pain, but easy to implement. The VsCode method of roaming though sounds like quite a bit more work. Better for sure, but not something we're about to get to any time soon.

Why not? It could be developed with community support. The source code to do this is already available in the VS Code repository, it is production-tested, and it includes tests...
As an aside I would hope that at a minimum WT should have extensibility as a major milestone in the roadmap to allow people to develop plugins such as this.

@zadjii-msft
Copy link
Member

@zadjii-msft zadjii-msft commented May 20, 2021

I would LOVE to have community help implementing this!

Just because we don't have time on the schedule to design/implement a feature ourselves, doesn't mean we aren't willing to help the community with such a feature. I just don't want to commit to anything, if we haven't explicitly allocated engineers to finishing it ☺️.

<aside>
Yep, extensions is totally something we've been working on. #4000 is tracking that. That's probably the big 3.0 milestone feature. We still need to get some OS support worked out to help us - it's a little bit trickier to load actual native code extensions rather than just blobs of javascript 😆

@awakecoding
Copy link

@awakecoding awakecoding commented Oct 12, 2021

I'm taking a chance here to suggest exactly what I intend to patch on my own builds to fit my needs: modify GetBaseSettingsPath to check for an environment variable "WT_BASE_SETTINGS_PATH" and use it if it's present instead of the default path. I really don't need anything more than that, as I would just launch Windows Terminal with different environment variables to make it point to different directories with injected settings.

image

Is there any chance that such a small change could be considered? I don't care about the environment variable name, just that we can use an environment variable (or command-line parameter) to override the base settings path.

@DHowett
Copy link
Member

@DHowett DHowett commented Oct 12, 2021

I took a crack at writing up the open questions about how a configurable base (be it a command line argument, environment variable, etc.) would work over at #6687 (comment) 😄

@awakecoding
Copy link

@awakecoding awakecoding commented Oct 12, 2021

I took a crack at writing up the open questions about how a configurable base (be it a command line argument, environment variable, etc.) would work over at #6687 (comment) 😄

This looks good to me, is there a branch with a prototype for the suggested change? Also, while settings.json is the primary file used by Windows Terminal, would it better to override the directory containing settings.json rather than the full path to settings.json, such that if Windows Terminal decides to store more files in the future, we wouldn't need to modify it again to override additional paths? Overriding the base path containing all files appears to be the safest option long term.

@patricknelson
Copy link

@patricknelson patricknelson commented Oct 19, 2021

Thanks for calling that out @DHowett

Hmm… since some of us want to synchronize profiles and others want the ability to parameterize via CLI which profile to use, have we considered separating this into two components? i.e.

  1. Directory to load profiles from
  2. The actual JSON file to load (must be a file, not a path and cannot be relative)

I say this since it might help to abstract away our concerns of allowing it to be roaming whilst also facilitating parametrized variability without being too tightly bound to the actual path. For example, both wt -c profile1.json and wt -c profile2.json would still work and are separate from where we decide to put them. This also suggests of course that, if the directory itself isn’t provided as a parameter as well (or some kind of env var, cringe I know) that you’ll have to devise a sane default. Presumably it’d still be in the current directory where this file is already stored and/or also configurable at some higher global level, wherever that may be.

I’m just trying to offer a concept that might help reconcile these two features amicably without it getting too complicated later on. 🤞

@DanielLaberge
Copy link

@DanielLaberge DanielLaberge commented Feb 9, 2022

Please consider making this issue higher priority, or #6687, whichever is easier to implement.

I suspect a lot of users are suffering from this pain point: they work on multiple machines and currently have no means of loading profiles from one shared location like OneDrive or Dropbox, etc. Having to manually copy and paste profiles across all our machines, everything something is added or changed is frustrating and shouldn't be required in this day and age.

The amount of comments and duplicated issues in this and #6687 should be a good indication of the interest.

@thernstig
Copy link

@thernstig thernstig commented Feb 10, 2022

Take inspiration from VS Code, the same way you took inspiration for the command pane from VS Code. They have authentication providers that can be used to sync settings. With logs, conflict resolution etc. etc. They spent a good chunk of UX on this already so I believe there is much to gain to just look at their solution UX-wise.

@stevenvolckaert
Copy link

@stevenvolckaert stevenvolckaert commented May 5, 2022

What is the status on this feature request?

Is it possible somehow to roam the settings across several computers at the moment, and if so, what's the most recommended way to do it?

Is the symbolic link workaround mentioned here still the way to go?

Thank you very much for your insights!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Settings Help Wanted Issue-Feature Product-Terminal
Projects
Specification Tracker
  
Spec Needed ❓
Development

No branches or pull requests