IEnvironmentService#userHome is deprecated

[bpasero]

I recently cleaned up the environment service for web and one outcome is that userHome is actually not known upfront until resolved later from the remote in web. For that case we do have a IRemotePathService#userHome that checks the remote and falls back to the local user home if possible.

I would like people to adopt the remote path service if possible. One catch is that the method is async since it needs to resolve the remote environment if there is one.

Outcome of this should be that no-one depends on IEnvironmentService#userHome anymore.

[sandy081]

@bpasero In ExtensionTipsService, it is being used to check local installables. I already have a check for web and do not do these checks. I only want to look for installables on local machine and I do not want to check installables on remote environment. Any suggestions how to go forward?

[bpasero]

Hm, why would we not show an extension tip checking for installed tools on the remote?

[sandy081]

We cannot treat all remote environments same. For eg., Dev containers what does it mean looking for installables in it? Does it makes sense?

I also think it is not intended to look for different kind of installables in the remote machine and prompt them in the remote window which does not need them at all. I see remote window is scoped to a workspace.

[bpasero]

If you feel that web/remote should not have these tips, then I suggest to split the service into 2: web and native and only do the one in the one case.

[isidorn]

@bpasero labelService depends on this being sync, if we change this method to be async than all callers of labelSerivce.getUriLabel will have to become async and that pretty much means the whole world. Is there an alternative approach here?

[bpasero]

@isidorn I guess, the alternate approach is to have sync access where userHome essentially becomes URI | undefined, that is it will be undefined until resolved (probably indicated with some event)?

Still, I would not want to have this on the IEnvironmentService, rather the remote path service as today.

[isidorn]

@bpasero that makes sense. If you introduce that URI | undefined call and the event in the remotePathService I will happily start using it.

[bpasero]

@isidorn I added IRemotePathService#userHomeSync

[isidorn]

@bpasero thanks.
@weinand fyi since I did changes in loadedScriptsView

[roblourens]

Did this in the QueryBuilder - tried to make it async to do this properly but it spiraled out of control.

[alexr00]

@bpasero what is the preferred way to get the local userHome even when there is a remote userHome now? For the simple file picker I need both.

[bpasero]

@alexr00 you can always depend on INativeEnvironmentService to get the userHome which will be of type URI and never undefined. My plan is to remove userHome from the normal IEnvironmentService and only have it in the native part. That is the only place where it is and can be defined.

[bpasero]

Since we are getting close, assigning myself for final cleanup and moving to April.

[Tyriar]

FYI my refactor broke the SSH extension as local terminals need to be launched before the remote connection is available. Moving to userHomeSync.

[alexr00]

@bpasero I had to move some things around to not break layering and use INativeEnvironmentService in simplefiledialog.ts. Pull request #95198

[alexr00]

Simple file dialog is done.

[bpasero]

I decided to go with the following solution:

• IRemotePathService is renamed to IPathService and should be used in all cases where you want the correct path behaviour for both remote and local environments
• there is userHome which is Promise<URI> that will always be defined and either be the remote user home or local (even for web serverless there will be a good fallback: vscode-remote:<remote authority>/)
• there is resolvedUserHome which is of type URI | undefined that is being resolved on startup but maybe undefined until resolved

There is a slight semantic change from the old behaviour: if you used to use IEnvironmentService#userHome and now switched to IPathService#resolvedUserHome you will get an undefined user home on VSCode desktop, even if a local userHome is present for as long as the remote environment is not resolved. If you must fallback to the local userHome, you need to use the native variants of the environment service yourself.

//cc @isidorn @alexr00 @Tyriar @roblourens for potential customers

PS: noticed quite some usages of userHome.fsPath, I think that is not 100% correct because fsPath might not work well with remote URIs. I think fsPath should only be used for file URIs.