For Visual Studio Code (VSC) it is possible to install the Remote-Kubernetes extension which allows you to work directly with remote development environments, spinning them up, configuring them etc. More info here.
Is something similar possible for Spyder?
I am aware that a connection to a remote kernel can be made but this seems to require for the remote environment to already be running. Am looking for same functionality as the okteto up command in VSC.
Related
've looked around and can't seem to find the answer to this - probably because the feature is pretty new.
I tried the remote WSL:ubuntu connection on my windows desktop machine to connect to my WSL2 Ubuntu running on the same machine. This is pretty much perfect as it allows access to my Nvidia GPU under linux
Is there anyway I can do the same trick from my macbook? I can connect to the windows side of the desktop using the new remote tunnel feature but I'm drawing a blank on how to do for the WSL buried in that machine. It looks like it's just using the same remote connection feature so I'm thinking it should be possible but WSL2 network is not exposed the same way you can with a VM or other machine.
The desktop has way more everything than my macbook including a nvidia GPU I want to use for some machine learning.
I can do it from the desktop itself - but it's nice to be able to use that machine from my macbook at certain times of day.
I have recently started using VSCode so I'm on the learning curve with it - it may well be that it's not possible using the new remote tunnels - or requires some messing with adding a new hyper-v bridged adapter to the WSL installation. I'm hoping against hope there's an easy solve that I've somehow missed.
I tried setting up the remote tunnel as per https://code.visualstudio.com/blogs/2022/12/07/remote-even-better but it seems to setup a server to access windows not the WSL2 service.
Thanks for any help!
I had a similar problem and found this github issue. While the developers are looking into including this feature, you currently will need to install the VSCode CLI directly in WSL. You can find the downloads here
Notes
I would recommend the x64 CLI download in the Linux section. It will download a tar.gz file which will have a file named code in it when extracted.
The tunnel will launch from wherever you place that code file, so I put mine in the ~/ (home) directory.
You can then open a tunnel using the command ./code tunnel from that location. You can replace the . with the path to the code file to open the tunnel while in a different directory, i.e. ~/code.
You can still launch a tunnel from Windows with code tunnel. (note that this command does not have ./)
Background:
At work I develop either in a virtual machine on my Windows laptop, or in a desktop workstation via a remote desktop app. Both environments are Ubuntu.
I have recently started to enjoy using VSCode, with the Remote SSH plugin. But I have to manually copy my setup .vscode/ folder to each project. I work actively in 10-20 projects, which makes this a bit of annoying.
All projects have the same setup and file structure, and both environments are setup the same. It feels like I could automate this more.
Using 3rd party tools is not applicable for me, since I cannot install whatever I want. Native support is important.
Question:
Is there any way for me to setup VSCode settings and tasks on my hosting Windows machine, but use them on the remote side after starting an SSH session of VSCode?
Since I mostly develop Web, using nginx, PHP and MySQL, I have ported my WebDev-environment entirely to WSL2.
Since performance is very important, all my web-related projects reside on the WSL2-vhdx file /home/user/Projects/Web. In WSL2 I've installed all my necessary tools for a nice and neat Linux-like experience, Docker, GIT, etc.. This combined with VSCode remote integration works very well.
Now, I'm digging into building Flutter-Apps, and my Flutter-environment is installed on the Windows side. My Flutter-related projects reside on D:\Projects\Flutter which is a partition, and NOT USED in WSL2 in any way. Building Flutter-apps with flutter-windows-sdk and VSCode works neatly.
But, the problem is: Now I've my project files scattered all across my computer. Web-stuff in a WSL2-vhdx-file and Flutter-stuff on the D-partition.
Is there a way to build flutter-apps with Flutter, while having the project-files stored on a WSL2-vhdx-file, in combination with VSCode-remote and an Android-emulator?
I tried creating a test Flutter-project on the \\wsl$ network mount, which didn't work.
Moving my web-related project files to the D:\ partition of Windows is no option, since the I/O mounts in WSL2 are extremely slow.
I got it working, reliably with adb connect 192.168.xxx
For anyone interested, see my full blog post here: https://dnmc.in/2021/01/25/setting-up-flutter-natively-with-wsl2-vs-code-hot-reload/
Is there a way to build flutter-apps with Flutter, while having the project-files stored on a WSL2-vhdx-file, in combination with VSCode-remote and an Android-emulator?
I'm assuming (based on the mention of VS Code Remoting) that you want to run the extension in WSL. I haven't tried that specifically, but I have run Flutter inside WSL and also connected a VS Code Remoting session to an Android emulator in the cloud, so I would expect this to work.
You'll need to make sure you set up the Flutter SDK inside WSL (so you can run flutter commands inside WSL - it should be the Linux version of the Flutter SDK and not the Windows one if you're using the zip).
To have your emulator show up in flutter devices from inside WSL, you will likely need to run adb tcpip 5555 from the Windows side (this means you need an Android SDK in Windows) - this will tell your phone to listen on TCP port 5555. Then you'll need to run adb connect [phone ip]:5555 from inside WSL (this means you'll need an Android SDK in Linux). If all goes well, the phone should then show up in adb devices and also be picked up by the device selector in VS Code.
I tried creating a test Flutter-project on the \wsl$ network mount, which didn't work.
It's not clear what went wrong here, though my first guess would be that maybe the UNC path isn't supported - if you map a drive letter to it does it make a difference?
While this isn't an officially supported setup, feel free to raise issues in the Dart-Code repository on GitHub with any issues you have. It's not a priority, but I would like for VS Code Remoting (including WSL and Docker) to generally work for Dart and Flutter dev.
Anytime you're crossing/sharing the file-system boundary from windows to wsl you're paying a massive cost in speed/time.
With the setup you've described I'd consider trying to self-host the browser based VSCode.dev inside wsl - checkout details instructions here: https://medium.com/geekculture/3-steps-to-code-from-anywhere-45401247f479
Personally I've settled on running VSCode and docker inside a Linux VM on Windows, and have a 96% time saving in things like running up a server and watching code for changes making this setup my preferred way now.
The standardisation of devcontainer.json and being able to use github codespaces if you're away from your normal dev machine make this whole setup a pleasure to use.
see https://stackoverflow.com/a/72787362/183005 for detailed timing comparison and setup details
How can I interact with the code on my Google App Engine instance from Visual Studio Code?
You can now run Visual Studio Code from the Google Cloud Shell using
https://github.com/cdr/code-server/
It comes down to downloading code-server, starting it and using the Web Preview functionality of Google Cloud Shell to use it.
See also:
https://medium.com/#chees/how-to-run-visual-studio-code-in-google-cloud-shell-354d125d5748
You can use SSHFS to mount a remote directory on a Google Cloud Virtual Machine (VM). It is very easy to setup and use compared to VNC or FTP:
First you have to access the VM via ssh. This is actually very easy and you don't need to generate any keys yourself. Just go to the console then: Compute Engine > VM Instances, then locate your instance and click on the SSH button at the far right. Tutorial and more info here.
Install SSHFS on your machine. If you have a mac, you can use brew cask install osxfuse and then brew install sshfs.
You are ready. Just type sshfs [you_user_name]#[external_ip_of_vm]:[directory_on_vm_to_mount_to] [local_mount_point], eg. sshfs john#35.222.222.1:/home/john ~/john-vm.
If you decided to setup VNC, here is a link to a very good tutorial on how to set it up on GC. And here is another link on how to setup SFTP.
You can check VSCode remote as well. It was recently developed and is already in quite stable stage. Probably Remote SSH will help you the most in your case.
I have a dedicated machine with Windows Server 2012.
When I debug service fabric in local environment, I only need to click Run in Visual Studio and the cluster creation and all the setups a performed automatically. I don't have to call any scripts or configure the cluster.
Is there a way to have such easy creation of a cluster on a remote machine without any manual config editing and without VS installed on the remote machine?
I have read how to install a cluster on-premises, but I don't want to configure anything. Guess if Visual Studio can figure out the right configuration, there could be a way to simplify the process for a developer.
Assuming that you're looking to set up a one-box configuration on the remote machine, you can do that as follows:
On the remote machine, set up a dev environment using the runtime and SDK only (no VS tools).
In an Admin PowerShell, run c:\Program Files\Microsoft SDKs\Service Fabric\ClusterSetup\DevClusterSetup.ps1.
This will set up a local cluster using the same configuration used by Visual Studio. In fact, all Visual Studio does is trigger this setup script.
Figured out that there are predefined templates for cluster's manifest. They are located inside Service Fabric SDK, \Microsoft SDKs\Service Fabric\ClusterSetup\NonSecure. Visual Studio use them to create a new cluster for development.
Not sure if we are able to obtain these configs without VS installed, but at least we can copy them from another development machine.