Bringing Remote Closer to Local: 2025.2 Highlights | The JetBrains Platform Blog

Our goal is to make remote development with JetBrains IDEs feel just as reliable and consistent as working locally does. Recently, we’ve made progress towards this goal in core areas like the editor,

The JetBrains Blog

For those lucky enough to be at the SciPy conference in Tacoma, WA: One of our core developers, CAM Gerlach, will be giving a talk tomorrow (Friday 11 July) at 2:35 PM in Room 317 to show off our work in order to support remote development. https://cfp.scipy.org/scipy2025/talk/X7S9PA/

CAM will also provide a short update on what we've been up to as part of the SciPy Tools Plenary at 10:00 AM on the same day.

#SciPy2025 #Spyder #RemoteDevelopment

Remote development for students and indie researchers with Spyder SciPy 2025

The last 10 years have witnessed the rise of the PyData ecosystem to become the lingua franca of scientific computing. Behind that incredible success, no doubt, there has been its open source nature, which allows students and researchers in any part of the world to use it at no cost. However, the fact that the ecosystem is a public good doesn't necessarily make it a democratic one. Although all PyData resources (i.e. its libraries and documentation) are free, the ecosystem still requires a good amount of technical knowledge to set it up and get the most out of it. This is especially true for remote development. It's not an easy task to move code developed locally to HPC clusters or the cloud in order to access a larger pool of resources (memory, CPUs or GPUs) to execute it. Perhaps the simplest workflow to do that involves logging through SSH to the remote machine, creating a Python environment there, moving your code using the `scp` command and finally running it. That's certainly not straightforward for many scientists and engineers, but doable. However, what happens when your code doesn't work because the local and remote environments are slightly different? Or when you need to do some adjustments to make it work remotely? Then the local and remote versions of the code start to diverge and you're more or less forced to work on an SSH terminal for remote development, which is atrocious. A possible solution to that, using OSS tools, is to set up JupyterHub and JupyterLab on the remote machine and work from the latter. But without IT staff to rely on for help, that could be a daunting endeavor. That's even more difficult in third-world countries because that staff is either small or non-existent. Spyder 6.1 aims to democratize this process by drastically simplifying what is required from users to get started with remote development. As it'll be shown in the first part of this talk, all users have to do is enter their SSH credentials and decide what packages they'd like to use for their code. Then Spyder will establish a connection to the remote machine, install a server there (called Spyder Remote Services) to handle all facilities required for remote development, and create a Conda environment with the requested packages. Finally, by simply opening an IPython console for the machine, users will be ready to run their code on it and graphically upload/download data sets or other files to/from it. The second part will describe how the architecture behind these enhancements was carefully designed to make it easily extensible by third-party plugins. Spyder Remote Services is a Jupyter Server extension, so it can be customized by other extensions and also installed in an existing JupyterHub deployment. On the Spyder side, the Remote Client plugin offers a context manager to interact with the server API as needed. This is no small detail because the remote facilities of other IDEs (e.g. VSCode and PyCharm) don't offer any way to do something similar.

Our first major milestone for remote development in 6.1 landed last month!! 🤩🎉

🌐 After starting a remote console, you’ll be able to browse the remote filesystem in Spyder!

Stay tuned for more cool updates in the coming weeks 😎

#Spyder #RemoteDevelopment #Python #IDE

There’s a Linux File Explorer built into Visual Studio!?! - C++ Team Blog

The Remote File Explorer in Visual Studio provides developers with a convenient way to browse, view, and edit files on remote machines—directly from within the IDE. It’s a powerful tool for managing remote environments without leaving your development workflow. Scott Hanselman published a new YouTube video to his channel, taking us on the journey of […]

C++ Team Blog
There’s a Linux File Explorer built into Visual Studio!?! - C++ Team Blog

The Remote File Explorer in Visual Studio provides developers with a convenient way to browse, view, and edit files on remote machines—directly from within the IDE. It’s a powerful tool for managing remote environments without leaving your development workflow. Scott Hanselman published a new YouTube video to his channel, taking us on the journey of […]

C++ Team Blog

😎 Did you know that in Spyder 6.0 it’s very easy to connect to remote servers and run code in them?

🤗 You can read all the details about the work behind it in our blog from three months ago!

https://www.spyder-ide.org/blog/spyder-6-remote-development/

#Spyder #RemoteDevelopment #Python #IDE

1/2 Good afternoon, chaps and chapettes! I woke up in a rather "fake" British mood today for whatever reason (🇬🇧🎩🧐).

I just want to say that Coder (https://github.com/coder/coder) is absolutely fantastic.

I've played with Codespaces and JetBrains Gateway in the past, but as a local-first, self-hosting sort of bloke, I never quite bought into the hype. Coder, however, is different. It really makes me more productive.

#Coder #OpenSource #RemoteDevelopment

GitHub - coder/coder: Provision remote development environments via Terraform

Provision remote development environments via Terraform - coder/coder

GitHub

Just past month I consulted a company, and I said they shouldn't renew #JetBrains, and fully transition to #VSCode and Coder.

Past week they did. They took three days to replicate their development environment, and a week to move from their muscular memory.

Nothing against JetBrains, but their products feel like 2005 crap on 2015 interfaces and 2025 promises.

#IDE #Programming #Technology #Containers #DevContainer #RemoteDevelopment #JavaScript #JS #PHP #Rust #Go #C #Node #nuxt

Nah, I’m good with my editor
87.7%
May be for some new projects
5.2%
I’m migrating soon
1.9%
I use my own LLM
5.2%
Poll ended at .