5 ms·

Vagrant’s popularity seems to have died down with Docker containers but it’s by far my favorite way to make dev environments. Several years ago I worked somewh

Vagrant’s popularity seems to have died down with Docker containers but it’s by far my favorite way to make dev environments. Several years ago I worked somewhere that prohibited web browsers and development tools on laptops. If you needed to use a browser, you’d have to use one over Citrix. If you needed to code, you’d use a VDI or run the tools in a VM. At the time I thought their approach was clinically insane, but I’m slowly starting to appreciate it.

tacticus 2y ago
This is the practice in many government sites these days. Except the vm is some old windows version without any tools on it. no shell access. can't actually do anything useful on there at all. VDI systems could work if implemented properly. but that's the last thing a security team actually wants to do.
- dacryn 2y ago
  VDI is actually preferred by our security teams, because they have complete deep packet inspection on literally all traffic going in and out. On our laptops, there are still some flows that avoid the vpn etc..
buildbot 2y ago
Vagrant is still kicking! But yeah not as popular as back in 2014-2016? A hybrid(?) alternative is enroot, which is pretty neat IMO, it converts a docker container into a squashfs file that can be mounted rw or used in an ephemeral way. https://github.com/NVIDIA/enroot https://github.com/NVIDIA/enroot
pmontra 2y ago
A customer of mine still uses vagrant on a project, for local development. That project started in 2016. We are developing on a mix of Linux, Mac, Windows and it's not as straightforward as it could be. Linux is easier, Windows is messier. A newer project fires up VMs from a Python script that calls an adapter for EC2 (with the boto library) when run on AWs and for VirtualBox (by calling VBoxManage) when running locally. That allows us to simulate EC2 locally: it's a project that has to deal with many long jobs so we start VMs for them and terminate the VMs when the jobs are done. That also runs better on our mix of development systems. WSL2 helped to ease the pains of developing on Windows. We call the native Windows VirtualBox, not the one we could have installed inside WSL2, but we keep most of the code that runs on Linux.
arcanemachiner 2y ago
I still like Vagrant. But I believe it's yet another victim of the Hashicorp license change debacle from a year or two ago. Unlike with Terraform/OpenBao, I know of no community effort effort to keep the open-source version of this project alive. The latest open source version is still available on the Ubuntu repo, but who knows who long it will work until somefor of bit rot occurs.
- fancyswimtime 2y ago
  more so a victim of speed
- pizza234 2y ago
  > I still like Vagrant. But I believe it's yet another victim of the Hashicorp license change debacle from a year or two ago. The license change is irrelevant - from the licensing page: > All non-production uses are permitted. Devs who use Vagrant in a development environment can do it as they used to do it before. > The latest open source version is still available on the Ubuntu repo, but who knows who long it will work until somefor of bit rot occurs. Hashicorp products have always been intended to be downloaded from the website, since they're statically linked binaries (I don't like that they're huge, but matter of factually, they make distribution trivial).
spike021 2y ago
At my first job almost 10 years ago we had the concept of "X-in-a-box" using Vagrant + VMs and I miss that pattern so much ever since (multiple job skips later). None of my jobs since have had any semblance of a better way to set up a local dev environment easily. It was just way easier to encapsulate services or other things in a quickly reproducible state. I digress..
hresvelgr 2y ago
Devcontainers[1] are the new incarnation of this pattern. We use them at work and they are a dream for onboarding new developers. The only downside is the VSCode lock-in but if that's a concern there's always DevPod[2]. [1] https://containers.dev/ https://containers.dev/ [2] https://devpod.sh/ https://devpod.sh/
- bluehatbrit 2y ago
  It looks like the team behind it have been moving it towards more of an open standard over the last year. There's now a CLI reference implementation, and the Jetbrains IDE's have an implementation for it. There's also a thread for Zed about a path to implementing it there [0]. Hopefully it'll become a bit more common over 2025. [0] - https://github.com/zed-industries/zed/issues/11473 https://github.com/zed-industries/zed/issues/11473
- roland35 2y ago
  I think vs code is the easiest way to set up dev containers, but once they are created I mostly just shell into them and use neovim!
flyinghamster 2y ago
I started using Ansible a few years back to set up VMs (or Raspberry Pis) with a consistent environment. Once I wrapped my head around it, I've found it very nice for any situation where I need to treat systems as livestock rather than pets.
- bloopernova 2y ago
  I use Ansible in local only mode to install/configure macOS as a development environment. Works well with Homebrew, and copies all the config files that devs often don't set up.
jsjohnst 2y ago
> At the time I thought their approach was clinically insane Let’s be clear, it’s still clinically insane, even if marginally rationalized.

tacticus 2y ago

This is the practice in many government sites these days. Except the vm is some old windows version without any tools on it. no shell access. can't actually do anything useful on there at all. VDI systems could work if implemented properly. but that's the last thing a security team actually wants to do.

dacryn 2y ago
VDI is actually preferred by our security teams, because they have complete deep packet inspection on literally all traffic going in and out. On our laptops, there are still some flows that avoid the vpn etc..

buildbot 2y ago

Vagrant is still kicking! But yeah not as popular as back in 2014-2016? A hybrid(?) alternative is enroot, which is pretty neat IMO, it converts a docker container into a squashfs file that can be mounted rw or used in an ephemeral way. https://github.com/NVIDIA/enroot https://github.com/NVIDIA/enroot

pmontra 2y ago

A customer of mine still uses vagrant on a project, for local development. That project started in 2016. We are developing on a mix of Linux, Mac, Windows and it's not as straightforward as it could be. Linux is easier, Windows is messier. A newer project fires up VMs from a Python script that calls an adapter for EC2 (with the boto library) when run on AWs and for VirtualBox (by calling VBoxManage) when running locally. That allows us to simulate EC2 locally: it's a project that has to deal with many long jobs so we start VMs for them and terminate the VMs when the jobs are done. That also runs better on our mix of development systems. WSL2 helped to ease the pains of developing on Windows. We call the native Windows VirtualBox, not the one we could have installed inside WSL2, but we keep most of the code that runs on Linux.

arcanemachiner 2y ago

I still like Vagrant. But I believe it's yet another victim of the Hashicorp license change debacle from a year or two ago. Unlike with Terraform/OpenBao, I know of no community effort effort to keep the open-source version of this project alive. The latest open source version is still available on the Ubuntu repo, but who knows who long it will work until somefor of bit rot occurs.

fancyswimtime 2y ago
more so a victim of speed
pizza234 2y ago
> I still like Vagrant. But I believe it's yet another victim of the Hashicorp license change debacle from a year or two ago. The license change is irrelevant - from the licensing page: > All non-production uses are permitted. Devs who use Vagrant in a development environment can do it as they used to do it before. > The latest open source version is still available on the Ubuntu repo, but who knows who long it will work until somefor of bit rot occurs. Hashicorp products have always been intended to be downloaded from the website, since they're statically linked binaries (I don't like that they're huge, but matter of factually, they make distribution trivial).

spike021 2y ago

At my first job almost 10 years ago we had the concept of "X-in-a-box" using Vagrant + VMs and I miss that pattern so much ever since (multiple job skips later). None of my jobs since have had any semblance of a better way to set up a local dev environment easily. It was just way easier to encapsulate services or other things in a quickly reproducible state. I digress..

hresvelgr 2y ago

Devcontainers[1] are the new incarnation of this pattern. We use them at work and they are a dream for onboarding new developers. The only downside is the VSCode lock-in but if that's a concern there's always DevPod[2]. [1] https://containers.dev/ https://containers.dev/ [2] https://devpod.sh/ https://devpod.sh/

bluehatbrit 2y ago
It looks like the team behind it have been moving it towards more of an open standard over the last year. There's now a CLI reference implementation, and the Jetbrains IDE's have an implementation for it. There's also a thread for Zed about a path to implementing it there [0]. Hopefully it'll become a bit more common over 2025. [0] - https://github.com/zed-industries/zed/issues/11473 https://github.com/zed-industries/zed/issues/11473
roland35 2y ago
I think vs code is the easiest way to set up dev containers, but once they are created I mostly just shell into them and use neovim!

flyinghamster 2y ago

I started using Ansible a few years back to set up VMs (or Raspberry Pis) with a consistent environment. Once I wrapped my head around it, I've found it very nice for any situation where I need to treat systems as livestock rather than pets.

bloopernova 2y ago
I use Ansible in local only mode to install/configure macOS as a development environment. Works well with Homebrew, and copies all the config files that devs often don't set up.

jsjohnst 2y ago

> At the time I thought their approach was clinically insane Let’s be clear, it’s still clinically insane, even if marginally rationalized.