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

Ability to specify remote project directory path in host settings #409

Closed
tvvignesh opened this issue Aug 18, 2020 · 7 comments
Closed

Ability to specify remote project directory path in host settings #409

tvvignesh opened this issue Aug 18, 2020 · 7 comments
Labels
caused by vscode The issue was caused by a VS Code (update) question remote Remote Development

Comments

@tvvignesh
Copy link

Hi. I have been using Project Manager extension for a long time now and its amazing. And recently, I started trying it out for Remote SSH as well, but had a suggestion.

Project Manager currently maintains a separate settings context in the remote VM which is great but I would like to specify projectManager.git.baseFolders for the remote in my host machine itself so that I don't have to specify it again even if I destroy the VM and re-create it (in such cases, the base folder setting will be lost since its in the VM).

Since I run my VM with Vagrant and I destroy VMs sometimes, I would have to configure project manager every time I do this. Also wondering if something similar is possible for other extensions as well.

Hope this makes sense. Thanks.

@alefragnani
Copy link
Owner

Hi @tvvignesh ,

First of all, thank you for your kind words. I'm glad to know you like the extension.

About your scenario, I'm sorry to say, but it is not possible today. To be able to have access to Git repos inside the remote, the extension needs to be installed there, and the settings aren't shared between the host and the remote. This is a VS Code limitation.

I don't use SSH so I don't know if you have the chance to provide additional setting to VS Code. Using Docker I can define settings in devcontainer.json file, so I could define the git.baseFolders there.

Hope this helps

@tvvignesh
Copy link
Author

@alefragnani Thanks for your quick reply. I am running on containers but within the VM created by vagrant. So, if I destroy the VM, even if I have a devcontainer file with settings, that will also probably be gone since its in the VM.

Anyways, I hope someday this would be possible or atleast we will get the ability to mount the settings from the host to the machine rather than doing it ourselves. You can close this issue if you want. Thanks again.

@alefragnani
Copy link
Owner

@tvvignesh looking at VS Code documentation about Remotes/SSH (https://code.visualstudio.com/docs/remote/ssh) I just find out that it should share the settings (https://code.visualstudio.com/docs/remote/ssh#_ssh-hostspecific-settings). Also, it appears you can say which extensions should be always installed (https://code.visualstudio.com/docs/remote/ssh#_always-installed-extensions). It appears it already support what you need 🤔.

I think you could take a closer look at this docs for info. If it doesn't work as it says, open an issue in VS Code repo. The VS Code team is eager in make Remote works the best way possible.

Hope this helps

@tvvignesh
Copy link
Author

tvvignesh commented Aug 21, 2020

@alefragnani Yup. While I am aware of it, the problem is that if you destroy your VM and recreate it, the host specific settings will also get destroyed and you have to copy paste the settings again incase of project manager. Rather if the settings were automatically synced or mounted from the host on remote creation, that would be even more easier.

But I guess I am just too lazy 😅 I can work with this very minor limitation since I am not destroying the VM every minute or hour but rather once in a week or month or so.

Btw, I do have project manager in the always installed extension config. So, that works without issues. The only issue is getting the settings synced. Thanks.

I am not sure if Project Manager can achieve this by itself or this has to be done by the VSCode team. Either way, feel free to close this issue since this is a minor one.

@alefragnani
Copy link
Owner

If the VM setting doesn't conflicts with your local settings, you could merge them. The extension shouldn't bother about unreacheable base folders.

The limitation, if that's the case, is on the VS Code side. When you connect remotely, you are connected "to some folder", not the machine itself. So, VS Code only knows (and gives access) to contents on that folder.

If sharing settings doesn't work as expected, I think they use a similar approach to .devcontainer.json file, for SSH and WSL. Another idea would be creating "remote settings on local settings file", so you could localy define settings for one or all your WSL/SSH remote connections. On both cases, I suggest you to check on VS Code and VS Code Remote repos for available issues. Maybe someone already reported similar requests.

Hope this helps

@tvvignesh
Copy link
Author

tvvignesh commented Sep 9, 2020

@alefragnani Hi. Just thought of updating this issue. I did try opting for the devcontainer.json approach like you suggested, but was not able to move forward due to this: microsoft/vscode-remote-release#2994

You can close this issue. I don't think, there is much we can do now.

On a side note, I had ignored favorites option in project manager so far. Just started using it today and it rocks! Switching projects has never been this easy. Thank you.

@alefragnani
Copy link
Owner

Hi @tvvignesh ,

I'm sorry to know it didn't worked out for you. But I think this will be achieved somehow by VS Code team in the future. I don't use remotes that much, but if I wonder an alternative in the future, I'll post some update here.

That's great to hear you did like the Favorites projects. This was the extension's original idea (the auto-detection came latter), and it's still my main usage, specially for Workspaces and Remotes.

Feel free to open/reopen the issue if you have any update from the VS Code team.

Thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
caused by vscode The issue was caused by a VS Code (update) question remote Remote Development
Projects
None yet
Development

No branches or pull requests

2 participants