You’re just a devcontainer.json away

So we are joined by Brigit Murtaugh, a product manager on the Visual Studio Code team at Microsoft, and one of the co-authors or the people working on the Dev Containers spec. Brigit, welcome to the show.

Thank you so much. I’m excited to be here.

We are excited to have you. We’re just learning about Dev Containers by way of a contributor to our changelog.com repo, who wanted to hack on the repo… And if you go to our repo at github.com/thechangelogchangelog.com and you try to hack on it, there’s a contributing doc, and it’s “Here’s how you get all set up”, and it’s macOS only, and it’s like very manual, install this, install that, blah, blah, blah… Kind of lame, but straightforward if you’ve done it before. But if you’re just a casual contributor, or you’re just getting started and you’d like to contribute, there’s really no easy on-ramp, until recently, when Chris Eggert, perhaps a colleague of yours also working - he works as an Azure resource manager - wanted to help us fix a bug. And before he could do that, he hooked us up with a devcontainer.json, and all of a sudden, boom, you could launch our repo in Codespaces, and be staring at our code, and running our code super-quick. And I was “This is cool.” And he pointed us to Dev Containers, we followed that trail, and we’ve found you. So here you are, here we are.

I’m glad the trail led to me and we can talk today.

So are we. It was awesome. I’m glad that you agreed to join us. I think we hit you up six ways from Sunday - LinkedIn, GitHub, email, and then by way of our co-friend, Brett Cannon, who also put in a good word, and we’re “We’re getting Brigit on the show, one way or the other.” I mean, you can’t say no when you get that many–

Well, you can say no, it just wouldn’t be polite.

Yeah. You could just block us from everything and say “These guys are creepy.” But thankfully you didn’t, and… Yeah, we’d love to learn more about containers.dev, what it is and what y’all are up to. Do you want to open up with us and just tell us what containers.dev is?

Yeah, that sounds good. So anyone listening, you can go to containers.dev in your browser, and you’re gonna see our overview spec site for the Dev Containers specification. And like Jerod was describing, dev containers - if you haven’t heard of them before - are this really awesome tool to help you get up and running with applications, or projects, or repos that you’re working on, without having to really download anything locally. And especially depending on your setup, maybe you need Docker locally, but you can also do other cloud-based environments, like GitHub Codespaces, like Jerod was describing, so that way you really don’t even have to download or run anything locally.

And essentially, there’s a couple of files that configure your dev container, and so that’s what was added to the Changelog’s repo. So there’s a devcontainer.json, which just describes the metadata about what should go into your container, and then you can also link out to a Docker file, which you may have heard of or be familiar with, if you’ve worked with containers at all, that can talk about some other things to install or set up for your environment.

And with devcontainer.json you can really extend it with what you want, specifically for a development environment.

[05:57] And so with containers in general, if you’ve heard of them or use them in other applications, you may think, “Okay, cool. That’s a way to standardize what my app has when it’s deployed, or when it’s off running in production.” But there’s a lot of other opportunities to standardize what your app is doing, or how you’re working on it earlier on, from when you’re developing it, to doing CI/CD, and testing. So then having a dev container now, which can have that same consistent tool set, and languages, whatever your app needs, from development all the way to production and testing, it really ensures that like I know how it’s running; when I’m testing it, I’m gonna get that same experience that’s deployed. Other teammates get that experience too, because it can all be checked directly into the source code, or the repo… And it tries to kind of take away some of the worries you may have, of like “Oh, Linux, or Docker containers seems hard or complex.” We really try to simplify some things with scripts, or other ways, that it’s “Hey, I can add this, and I can add really advanced functionality, but I don’t have to go learn everything about how to be a Linux scripting expert to get started.”

I love it conceptually. I know that when Docker first became a thing and people started using it, I thought of Docker as a thing to put production stuff in. And then I thought, “Well, I’ll just put my development stuff in there, and then when I’m ready, I’ll do like docker go prod mode”, or something, and I would be done. And what I realized quickly was that wasn’t the case. It was kind of you could do them both, but most people use it for dev, or like some people were using it for prod; back then, really, it was dev-first, and it was really cool to be able to ship your dev environment around to people via this Docker file. But what burned my mind back then was how different dev and prod really were with regard to the containers, and I guess the concerns of those containers. They always seemed to be slightly different, and that’s something that you guys point out on the website, is that dev containers and production containers often have different needs. And dev containers usually have a lot more needs. Is that right?

Yeah, exactly. So you could think of - if I’m opening up my favorite editor, IDE, and what am I typically using to work on my project. yeah, if it’s a Python app, I’m going to need Python installed, and I’m going to need that whether I’m in the process of creating my project, or if it’s deployed… But also, maybe I have some specific editor settings that I or maybe I have a theme, or maybe I have extensions or plugins; it’d be awesome if “Hey, that really helps with my development every time, especially if it’s language-specific extensions that really enhance my coding experience.” If I can just make sure every time I’m opening up my editor those are already there, that saves me time, and that helps if other people are working on this project, too. I don’t have to tell them, “Oh, hey, go check out this contributing file, and figure out all these extra things you need to install.” It’s “Hey, just make sure that you have your devcontainer.json in the branch you’re working on, and you’re good to go.”

That is kind of beautiful, that that can work like that. I mean, it’s been a while since Docker. I mean, Docker has been around, it’s gotten better, this has been more mature… And I kind of feel like the resistance is somewhat futile for this cloud world to take over our dev environments. We talked Cory Wilkerson a while back, I think it was called “Coding in the clouds”, honestly, with Codespaces, which was a cool title for the show… But I think ever since then, we’ve had this idea to get Changelog.com into a Codespace, or into this – Codespaces-friendly, essentially. And only until this commit, until this drive-by contribution to help us are we somewhat there. And the cool thing is is that person wanted to contribute. And I think this is really great for open source, right? this is not just good for like dev environments, and like plugins, and extensions, and themes, and all these extra things that make your time go fast, but also like - well, we would love to encourage folks not to just contribute, but like just to play a role in where our platform is going and where this community is going, in terms of how we entertain and inform developers over many, many years, decades now… Or at least one decade, maybe two decades, Jerod, if we’re lucky, right?

Round up…

Decade… Right?

We’re at decade now…

[10:00] It started as a contribution to get into the cloud, and I think this is kind of cool… But do you feel like - maybe Jerod this is more towards you… Do you feel like this is futile, this resistance towards like cloud dev environments running this thing like that? do you think resistance is just forget it?

I feel like you are attacking me personally at this point, because I am resistant… Well, as Brigit will probably point out,

Codespaces is very much in the cloud, insofar as you’re literally running it in a browser tab, right? And that’s one thing. But what this dev container thing provides is not just - it’s cloud-based coding, but you’re still local with your VS Code, for instance. And of course, as we talk about the spec and what your team’s desires are for this spec, it’s gonna be more than just VS Code, it can be more than just Codespaces… Of course, Microsoft is really front-running this idea and this spec…

I do think it’s probably futile, because there’s so much upside to the containerization, to the repeatability, to the sort of like your dev infrastructure as code, like having it all right there… And then just teamwork. Teamwork tends to be what makes the dream work. I don’t know; what do you think, Brigit? Is it futile?

I was gonna say the same thing; maybe that’s too cheesy, but you said it first, so… [laughter]

Sorry… I never let a cheesy moment go by…

Yeah. I mean, I think as well as we’re all these kinds of systems and tools and tooling get better… Like, we’re seeing cloud-based environment not be something where it’s like “Well, I’m probably going to lose all my work there. It’s not going to run right.” It’s like, no, it probably is going to be a pretty consistent, reliable experience. And then - yeah, if maybe you don’t have an internet connection, or there’s times where, I don’t know, maybe I just prefer to have it locally on my machine. Having that same, consistent dev container setup, so that way I could use it in local VS Code, and what we have is called the Dev Containers extension. Or I could even use it just on the CLI, so out of any kind of editor… Because what’s backing the Dev Containers extension, and what’s backing GitHub Codespaces is this CLI, that can read in “Hey, your project has devcontainer.json, so let’s go ahead and set things up right, so that way you can develop in this development container.” And so we’ve now open sourced that CLI, so hey, no matter where you want to code, you can have a consistent dev environment anywhere.

Yeah. I think for me the resistance has been against layers, like adding more and more layers… And for me, especially running on a Mac, Docker was always so slow. And I know there’s been a lot of work put into that. I think it’s gotten faster lately… I’ve just never liked the Docker dev experience, that’s why I was very excited that it was going to be like a production thing, and that eventually manifested, at least in terms of containers… But I just didn’t want so many layers. And very little upside, especially working on small or individual projects, which I often do. And so that’s my resistance. But when I see the upside, and when I see the effect of the layering not be as dramatic as it has been in the past… We’re like “Wow, it’s super-slow now, because I’m running through Docker… Whereas it could be super-fast, because I’m right here on my local machine.”

I think that I will not be as resistant in the future, as I have been in the past… At least I hope not to be. You know, I’m getting older, we do get set in our ways, and for a lot of us at a certain point progress just kind of goes on, and we just kind of stop at a certain place. Maybe I’ll get there, I don’t know. I hope not to, as a developer, but…

Yeah. I was just thinking, this reminds me of like a smell. This is something that I think Steve Jobs kind of talked about back in the day… One of the more famous kind of interviews, or quotes, I’m not really sure how you’d describe it, but one thing he said was you have to work backwards from the user experience. Right? I think this is an example of the smell; like, your user experience you’ve desired, Jerod, is just not what traditionally a cloud-based environment would really give you, or Docker would give you. It sort of like adds these layers…

[14:03] And so this is a problem that, Brigit, you and your team I’m sure are probably very keen on and very sure of, because you have to work from “What’s the user experience we desire?”, back from the tech. Versus “Here’s Dev Containers, and what it offers”, and fit it into these non-round holes. That’s really what I think comes to mind, is like “How close are we to this being the, I guess, magic/silver bullet?” Did you work backwards from the experience to the tech, or was it tech, and then “Hey, here’s this beautiful tech. Where’s the use for it?”

Yeah, I think definitely starting with user feedback, the users and what we want their experience to be. What we really hope to do with anything Dev Container-related, or even just beyond, in general product, VS Code sense, and all that… So we first published the remote development extensions in VS Code, where Dev Containers is one of them, in 2019, and that was really with the mindset of “Hey, we’re getting this custom more feedback that I want to develop in something that has maybe the tools that I already need, and I don’t need to clutter my local development environment, or it can be overwhelming.” Or for some of our other remote development experiences; like, we have a remote SSH extension, or we have a remote WsL, a Windows subsystem for Linux extension… And so with those, we also got similar feedback of “Hey, I want to use the Windows subsystem for Linux, but maybe it doesn’t interface with VS Code super-nicely, and I love VS Code, too. What can I do? I’m always like developing on a VM, or on my desktop in the office when I’m away… But it’d be great if I could just have something that’s like faster, and I don’t have to upload and download files specifically. It’s all just there already, and feels more built-in and more native.”

So I think like getting that feedback is really what sculpted of “Hey, let’s start investing in remote development”, as that’s something that people really need, and that’s where the market and user needs are going. And then from there - yeah, as we design new things with Dev Containers, and trying to make it easier for users to use, and helping them with a variety of apps, it’s always coming back to “What are they asking for?” What are our top feature requests and issues, and all that kind of stuff? Because all this - we really work in the open as much as possible, so getting that user feedback is something we really value, and we really try to incorporate it every step of the way.

Is this VS Code users, just like Visual Studio Code? Is there a difference between like Visual Studio Code and VS Code?

Same thing. If you want to write out the whole name of Visual Studio Code, you totally can. VS Code is the same.

When did it merge? Wasn’t that like a paid version that wasn’t open source?

Well, there’s Visual Studio…

Visual Studio is a separate IDE.

Right. Okay. Such a confusing thing for me. See, I’m still unclear to this moment right now. Clarity…

Yeah, it’s tough, because it broke off of Visual Studio, which was Microsoft’s big IDE. It still exists today, right? Still progressing… But VS Code, Visual Studio Code was – you remember the story of VS Code, Adam; we told it back in the day at Microsoft Build…

Yes.

Brigit, perhaps – we have you here, we have a VS Code representative with us… Maybe you can dispel this notion that I’ve floated into the ether before; as VS Code continues to get better, but also just get more stuff, more and more and more and more and more, it’s like, is there a future where VS Code is basically an IDE? Like, is it going to get so much that you’d say “Well, we have two IDEs”? Or is it always going to be a text editor with a bunch of niceties, and features? Just curious, from your perspective - is that something you all think about as a potentiality, something you’re trying to avoid etc.?

Yeah, I mean, I think at its core, we always call VS Code an editor rather than a full-fledged IDE, or an integrated development environment. And I think that it’s kind of somewhere in between. So it’s like maybe more than just like a super-simple editor without many additions; because you can have extensions that can do basically anything you can think of, and other kinds of support we’re adding, and everything with remote… I don’t think we would go to “Hey, eventually - yeah, it’ll just be an IDE, and that’s what we’ll call it.” But I think we just want it to be the tool that you can edit anything from anywhere, is kind of the tagline we’ve been adding on.

[18:08] In 2021 we released VS Code for the web, or VScode.dev. So you can just go in your browser, type in VScode.dev, and you’ll see a version of VS Code running just entirely there in the browser; you didn’t have to download anything. So with that, and then as we have a growing set of remote experiences, and just more extensions and features overall, I think it’s cool to see how much we can push VS Code in scenarios users are interested in, and contributing back as well… But we always keep things like performance and not being too overwhelming in mind as well. So we try to keep the bigger vision as well of meeting what users want, and what is more modern development, without being like “Let’s just build everything in.” I think you can kind of see it as there’s a series of extensions you install as well, or different things like that. It’s not just, “We’re gonna build in all of these extensions for you always”, or something.

I think that’s wise. I think it’d be a shame if VS Code became so full of stuff that it was a full-on IDE by default. I mean, heck, you wouldn’t really want to run that inside your web browser necessarily, because it takes so long to load up, or so much memory to run… So I’ve always liked that you had a clear break from Visual Studio, and a fresh start, and I think the editor over time has stayed relatively fast and lightweight, and it feels like you can just launch it immediately… And then from afar, I just see all the additional improvements and stuff and I’m just like “Wow, it’s getting very full-featured.” And then I’m like “Do they need Visual Studio eventually? Has it become one? Do they merge branches there?” But I think you guys have a clear vision of what you want to do, and I think it’s a pretty good one.

With regard to – what did you say? You said “Code anything, anywhere…” Was that the slogan?

Yeah, we like to say “Yeah, you can work on, edit code, anything from anywhere.”

Anything from anywhere. I like that one. So you’re kind of on the anywhere side, right? Like, your focus and your work is on the remote aspect, the anywhere aspect. How long have you been working on this spec in particular, Dev Containers? And when did you decide to take it beyond just a VS Code internal thing that allows VS Code to do remote, and containers, and stuff, to be like a spec that you want other people to contribute to, and other products and tool chains to adopt?

Yeah, so I’ve been on the VS Code team since 2020. And I first joined and focused on the remote extensions. We had three main remote extensions: WsL, SSH, and Dev Containers. And then over the next year as well we worked really closely with the GitHub Codespaces team, and they also support Dev Containers; just it’s in the cloud, instead of on your local machine.

And as we were working on our Dev Containers extension, and working with Codespaces, we saw “Hey, Dev Containers can be something broadly useful beyond just VS Code, or GitHub tooling, or Microsoft tools.” It’s something that people want to use even if they don’t use VS Code. Or maybe they can’t; maybe their company uses something else. Or maybe they’re doing all their work in the command line, and it makes sense to open it up as “Hey, this is kind of like a standard that other people, other tools, other scenarios can adopt, and it doesn’t need to be inherently tied just to VS Code.” It’s a general concept, it supports – instead of like becoming its own container orchestration format, we’re seeking to just enrich other ones. So we’re not trying to replace other things, we’re trying to say “Hey, how can we interact and interop with them, and just support people with what they want to do and want to contribute?”

So then we started openly working on the Dev Containers spec the beginning of last year, maybe the end of the year before… So it’s been a year, a year and a half or so. But I think like a vision going in was, “Hey, we don’t think Dev Containers have to be tied to VS Code.” And that was even when they were only a Dev Containers extension in GitHub Codespaces thing.

[22:06] So that’s why the file is like devcontainer.json. It doesn’t have to say specific things about VS Code in the file name or in its content. And we’ve even been taking steps as we’ve been working on the spec to generalize it beyond VS Code or Codespaces. So for certain properties in devcontainer.json settings, or extensions that may not make sense in other tooling, we’ve now extracted them to a top-level property for specifically VS Code and Codespaces. That way it’s like “Hey, if you use those tools - awesome.” They can handle it. And then over time, other supporting tools, as other tools decide to support the spec or contribute to it could also reserve their own properties in there as well. So it’s all under customizations [unintelligible 00:22:42.13] there could be any tool in there.

Yeah, and I think it’s really cool to open this up and have other tools, other sites, other cloud things adopted. I do think that Codespaces is such a killer intro to the possibility of using Dev Containers, because it reminds me - I don’t know about you, Adam, but it kind of reminds me of that deploy to Heroku experience… You know, the one-click button where you could take this current thing you’re looking at, deploy it as your own Heroku app, and be running it in the cloud. Those have been replaced with - I don’t know, deploy to Vercel, deploy to Netlify, deploy to whatevers… Maybe not replaced, but augmented in recent years. That experience, the fact that we can just say now “Just go to our repo, click on the little Code button in the corner, and say, Launch on Codespaces, or whatever the button says right there…”

Yeah.

…and literally, three to five minutes later… It’s not immediate; it’s close. Because of course, there’s lots of stuff that has to get set up inside of that container; that first run experience, in order for it to do its thing. And all of a sudden, there you are - you’re both looking at editing, and can execute code inside of what you were just staring at. Who doesn’t want that for their project? It’s awesome. Right, Adam? It’s killer.

For sure. It’s a beautiful thing. I mean, you need this for open source in particular. What a great thing for would-be contributions that just get stopped because it’s like “Oh, gosh, this contributing file… I love your stack, but I don’t want to mess my pristine machine up” or “I don’t want to deal with any of this stuff.” For whatever reason, it’s just there’s a blocker there. Or even I think – and when I was watching your YouTube series, Brigit, one thing I thought was pretty interesting was being able to jump around tech stacks. That’s kind of cool, right? Like, if you are traditionally a web stack developer, but you want to jump into a backend-focused thing or something like that, or into a whole new Python world, you can sort of move around different stacks.

So that kind of like encourages the possibility of polyglot, to some degree, or at least contributions to polyglot worlds. Even if it’s not something you’re like a primary contributor to, but you’re able to put your own contribution in, whether you’re a designer, or documentation, or whatever it might be; to be able to move around like that I think is a pretty interesting and compelling reason to consider the possibility with Dev Containers.

Yeah. I think that’s a great point.

So the contribution we have - it’s got a devcontainer.json file, it’s got a dockercompose.yaml file… At what part of this is the Dev Container spec, and what part of this is Codespaces? Where is the line, I suppose, in that world? Is it like they adhere to or support your spec? Do they have their own spec? Demystify, I guess, the ambiguity there between where the Dev Container spec comes into play for us in regards to this contribution, and then running that on Codespaces.

Yeah, so you can kind of think of the spec as essentially that devcontainer .json file. So we’re seeking to enrich other formats, whether it’s a Docker file, or a Docker Compose, or maybe potentially others over time, with metadata from the devcontainer.json.

[26:03] So it can include those tools, specific things, like we were mentioning. It can also be a spot where you can add or install other scripts, or technology, or parts of your tech stack there like you might do in a Docker file; you could instead do it in the devcontainer.json. We have ways kind of built-in to make that easier for you to add more features.

So really, devcontainer.json it’s going to be the core of “Hey, like this is what is defined by the Dev Container spec.” And then you can also then think of like a reference implementation for the spec, or what is an example of how other tools could implement the spec over time is a Dev Container CLI that we open sourced. So go to github.com/devcontainers/cli. You’ll see there, it’s like “Hey, that’s the backing CLI that Codespaces uses, and that the Dev Containers extension uses.” And that CLI is then how those tools are able to read in a devcontainer.json and build a dev container or a dev environment from it, and make sure that the spec is supported. So then if another tool or individual wanted to support the spec, they could use the CLI. And whether they integrated it into an editor, or just used it in a terminal, that’d be considering “Hey, I support the spec here. I’m using the reference implementation of the spec.” But that could also be if somebody wanted to make modifications to the CLI, they could contribute those back, or just use their own modified version, too.

So this is the essential Lego. Not the finalized Lego that you could build; these are the components that you could build to support essentially running code remotely, or in a Codespaces… So if I wanted to build my own Codespaces, essentially, I could use the CLI tool, I can use different things, and leverage, essentially, what you built to adhere to that spec and be able to do all those different things.

Yeah. If you want to build your own tool that supports Dev Containers, like you’re seeing in Codespaces, you’re seeing the Dev Containers extension, you can then use that same exact CLI, and then hook it up to specifically what your tool needs. So if your tool needed other kinds of things… Like, maybe you have your own settings or extensions or needs for those things, or other properties; maybe you work with secrets in a certain way - you could then make sure the version of the CLI you’re using respects or adds those kinds of properties.

What’s the experience like as a user of VS Code today? Let’s say I open up VS Code, a project, I’ve cloned a repository that has a devcontainer.json file. What does it change about the VS Code environment? Which extra buttons do I get, or what all does it do? …assuming Dev Container does what a typical dev container does. I’m sure there’s atypical things too, but just generally speaking, what does it do for the experience of VS Code?

Yeah, so VS Code will detect if you have a .devcontainer folder, or if you have a devcontainer.json, which could be in that .devcontainer folder, or at the root level of your project, and it’ll recommend, “Hey, it looks like your project has a Dev Container configuration. Reopen in there to develop even more effectively”, or something along those lines. And then you’ll have the option to reopen in that dev container, which will use the Dev Containers extension. So if you’re familiar with the VS Code model of programming, it’s essentially if you want different features, different functionality, you can install it through extensions. So we have a Dev Containers extension that then you can install from the VS Code marketplace, and that will give you all the functionality to rebuild dev containers, reopen within them, add dev container configuration files. So it’ll guide you through that process of creating a devcontainer.json, and adding things to it, adding the languages or toolsets that you need. So you don’t have to look at me like “Well, I’ve never used a devcontainer.json. I don’t know what to add, or what to do.” We try to guide you through that, through different quick picks, and different checkboxes. So you can be like “I want Git, and I want Python, and I want Node.” You can just checkbox all those, and it’ll be in your project, and then you can just reopen in it.

And the devcontainers.json, at least the one that we got from Chris Eggert , is super-basic. I mean, it’s basically 10 lines… And it’s mostly setting up a workspace, a couple of port forwards, and then pointing to the Docker Compose file that Adam was referencing. And the Docker Compose file is the one that’s actually doing the job of getting your container all set up for development.

So if anybody’s already using Docker Compose for their own personal development environment, all they need to do is add devcontainer.json, and point it to the right things; a little bit of configuration goes a long way, and now all of a sudden you can run that same environment in Codespaces. You can get the VS Code extras, as well as, hopefully, as time passes, other tooling that adopts this spec. So you’re really just a devcontainer.json away from opening up that environment to lots more people.

Yeah. I like that statement, “You’re a devcontainer.json away.” We can use that as a tagline.

Yeah, I like that too.

And you can even add more stuff to your devcontainer.json. I was mentioning “Oh, what if I’m thinking, I really just need Python in this project. How should I add it?” I could install it in the command line, but then either I have to install it locally, or if I install it in the command line in my container, it’ll get lost eventually if I kill this container… Should I install it in a Docker file, or somewhere else? So we have this concept called Dev Container Features. So that’s the steps that VS Code or Codespaces or other tools can guide you through via checkboxes of “Hey, here’s a list of features. Maybe you just want install one of them, maybe you want install a bunch of them.” And then it’ll list those in your devcontainer.json. And even if you’re not using tooling like VS Code, you can just add those to your devcontainer.json via a features property. So you can say features, and then name whatever feature you want to use. It can be one you create, or one that the community, or someone in your company created… We have a list that community members could contribute a feature, so that way it’s like “Hey, I wrote this really awesome feature for something I worked on, or something that I use, and I think other people want to use it.” You can add it to the index, too.

So how far do you go with that? Because I expect – we have so many different ways of specifying, like editor config, then you’ve got your VS Code config, maybe you’ve got your vim config, maybe you have your Git ignore… Of course, that’s just a file that’s in your repo, but… There’s just so many different ways that we specify how to configure our environments, and some of those we want to be global across the project - linters et., style rules, maybe requirements for documentation… I don’t know, there’s 1,000 different things you can think of. Some of those things are like personalized to the developer, and then other things are like “No, this is the whole project.” What do you guys have found - you probably have more experience with devcontainer.json files than anybody - that are like smart things that people are doing to share, and like “Hey, go ahead and put your editor config right here in your dev container”, or “No, that should be a thing that lives somewhere else”? What are you finding?

[34:08] I like the way you put it, of “Is this something that the project really needs, or is this something that I just like using, or that I need?” It’s really a helpful distinction. So I think if it’s something that’s super-specific, like “Hey, I like this editor theme” or “I like my editor sidebar configured this way, or this specific editor setting.” If it’s just a dev container that you’re using for your own personal projects, then totally put UI and very specific things in it. But if it feels like “Hey, probably not everyone is gonna love the same VS Code theme that I do.” It’s like “Okay, I can probably maybe not put that in a dev container that I’m sharing with my whole team, or the open source community on this project.”

So thinking about like “Hey, if this project really needs this language”, or if maybe this linting tool is really helpful, or… Maybe there are certain editor extensions, like language support extensions, like a Python, or a Java, or a C++ language extension for an editor. Those are probably really helpful additions, where yeah, maybe for some development you wouldn’t necessarily need it, but it’s going to make the development experience a lot better, and people aren’t probably going to like strongly disagree, of “No, I think my developer experience is way worse than them.” Then I think adding those kinds of things in, that feel like will be generally beneficial to open source community, or the other teammates that you have on your project are great things to add. And there’s so many things, so it can definitely be a lot of different options. But just thinking about how generally applicable they are I think is the really helpful first or fundamental step there.

Is there room for a .local file in that case? Maybe Jerod and I, this moves forward, and we keep loving it, and there’s a devcontainer.json in our repo, but let’s say I like a special flavor of something whenever I spin up my personalized container. Can I have a devcontainer.local? Is that a bad idea, to have sort of a localized version, where it’s like “Here’s the dev container, and here’s what it does normally. But after all that’s done, give me this, this and this, because I’m Adam.”

Yeah, there’s a few different ways you can handle it. So depending on the editor environment you use - so let’s say you’re using VS Code; there’s certain specific settings, you may be able to take in your editor, where then you don’t even need to set certain things in your dev container. VS Code has extensions to always install. So you could like set a list of extensions that you always want there, which could include language extensions, but also include theming, or other specific UI, or key bindings, or things like that.

But then thinking about other editors, or if you don’t want to use those kinds of extensions, it depends… You could actually have multiple devcontainer.jsons in a project, and then depending on how the supporting tool implements it, they can guide you for “Hey, which one do you want to use right now, when you’re working on it?” So maybe you could have your own version, that either yeah, maybe you’re not checking into source code, if you don’t want to confuse other people, or that’s maybe on your own branch that you have a few… So that way you can kind of have it of “Hey, I specifically need this for this scenario, so I’m gonna have this kind of dev container here. But then I need this other kind of scenario, so I’ll have a secondary one.”

That can also be helpful for maybe if you’re working on a monorepo that has different dependencies for different sub-parts of the project; then you can have multiple dev container.jsons there, depending on what you’re specifically working on, or what some of your other teammates are working on.

Interesting. Keep my local flavors. I like my local flavors. Gotta keep the local flavors

Yeah, you’re special, man. You’ve gotta keep it special. So when it comes to adoption, I’m googling around frantically as we talk, looking at, okay, is the Vim community trying to do some of this, is the Emacs community trying to do stuff? Some people are just switching; they’re just watching the VS Code. Other people are like “Ah, here’s an open source implementation of VS Code’s Dev Container API. Here’s a Neovim thing that does some stuff with Dev Containers…” So it seems like they’re out there, but they’re not established, 30 people supporting this one plugin etc. What do you think it’s gonna take to get more people on board and doing this, and maybe even contributing to the spec?

[38:08] So you kind of have like the editor side, but then you also have the cloud provider side, and you have two implementations - VS Code and Codespaces. But on both sides, you have like the open source, like Vim, Emacs, integrated into small projects, like Sublime Text, and then you have Codespaces, Gitpod, I’m sure there’s other ones… StackBlitz… There’s a lot of cloud IDE things, or web dev things in the cloud, and I’m just curious what adoption looks like, pr if there’s a clear path to that. I just wonder, as an author of a spec what it feels like to put a spec out there and hope that people use it.

Yeah, when we first were announcing, “Hey, we’re working on this spec, and we open sourced this CLI”, we announced it on, for instance, the VS Code Blog, or Codespaces channels too… But we wanted to emphasize “Hey, even if you’re finding out about it on the VS Code Blog or something, the point is it’s not just VS Code.” So I think like having that in our messaging has been really key, because I think that since Dev Containers for a while were just a VS Code and a Codespaces thing, some folks still totally understandably think, “Hey, well, if I’m not using those tools, I don’t need to add Dev Container to my project. I don’t really need to worry about it, or it’s not something for me to think about adopting in another tool”, or something like that.

So I think like getting the word out more, of like “Hey, it’s an open thing, and you can check it out here. And we’re super-looking forward to your feedback. We accept contributions, or we’re happy to talk to you about questions, feedback, contributions, and all that kind of stuff.” I think just getting that open dialogue and awareness out there has been really helpful. And chatting with folks who are part of different language communities, or who use different tools, or to drive different tools, and kind of getting their feedback of what are gaps that maybe the spec is missing, that you feel like Dev Containers overall could be better at, so that way we can prioritize that in the work that our team does, and also get additional feedback and see how we should shape the future roadmap.

And yeah, we have a section on the containers.dev site about supporting tools. You’ll see that it’s trickling out to some other like CLIs, and projects, and things like that… But I think also seeing more devontainer.json files, or .devcontainer folders, and other open source projects has been a huge help as well… Because then it kind of shows “Hey, folks who are part of this community, you can check out Dev Containers. You can use them.” Like, getting the word out there more, and getting feedback from those users too, of like “Hey, I’m using it for this kind of scenario, and it doesn’t work so great.” It’s like “Okay, cool, tell us more about that and see how we can make it better”, so that way it’s better for this whole community, and maybe other open source communities and projects over time.

When you get this feedback, what are some of the biggest hurdles to get over? What are the things that really stop people, or what are the things that really get people excited? Obviously, the usefulness, but what are the things that really push back against using it?

I think at the beginning it was just them not feeling like a very open, or like super-adopted thing, of like “Okay, cool. Yeah, maybe there’s good adoption in VS Code-specific tooling, but what other tools are using them?” So sometimes it can be like a chicken or the egg problem, where it’s like “Oh, should I support it or adopt it, and that’ll help other people adopt it? Or should I wait for other people to adopt it before I want to do it?” So thinking about “Is this for sure something you all are investing in, and going to keep open, and going to keep freely available, at no cost?” and that kind of stuff.

So I think establishing that trust and awareness with folks is definitely something that isn’t just like an easy formula of “Oh, yeah, here’s how we get the word out to everyone who might want to use this.” And “Yeah, they’re just gonna know, and trust, and understand that yeah, we really want to prioritize and invest in this.” But I think it’s something you can just kind of show through continued action of “Okay, we have an open community Slack channel. Hey, we have community discussions that we actually respond to, and really want your feedback on.”

[41:58] So just slowly trying to build that trust and understanding, and getting that open feedback channel over time has been really cool, but it’s something that we kind of needed to just experiment with over time, and we’re still figuring out; we’re still figuring out, “Hey, what are some cool open source projects that this would make sense to?, and it doesn’t feel like – we don’t want it to sound like “Hey, we think Dev Containers are for sure the best thing for you, and we know everything about your developers, your community, so you have to take this PR.” It’s more “Hey, here’s what Dev Containers are. We think they could be a good fit. We’d love to know if you’re open to this kind of PR, we can help you with it. Or is there something you feel like that we’re missing, that we could add, or we could change? What can we do to get there for you?”

I mean, it seems like to me the best pitch for cloud things is like “Hey, here’s an easy adoption avenue”, right? Like, you can be there with your deploy to cloud thing, or develop in cloud thing x, just like the one Codespaces works on github.com right now. And then on the indie side, like the developer side, I just feel like it’s such an easy sell, because it’s like “Hey, don’t you want your open source project to be immediately hackable?”

Yeah. More people can use it and contribute. That’s awesome.

Yeah. I mean, who doesn’t want that? And I think the demystification – so for us specifically, I know we kind of wanted a Codespaces set up for a little while, but Adam, and I thought, “Well, we need to talk to Cory and the Codespaces team.” I don’t think he’s on the team anymore, but when he was, he came on the show… And like have them help us to set up a thing that makes it all happen. And just the knowledge of “No, you can just have a devcontainers.json in your repo, and that’s all you’ve gotta have…” Seven lines of code, kind of a thing. Of course, different setups are going to be different. We have a Docker compose as well; you might have more stuff to do. But just “Oh, okay.”

And so I think that plays into this other thing you have on the website, which is the templates. You have kind of two subsections of the Dev Containers website. You have the features, which you talked about, but now you have the templates, which to me, I’m reading this - and help me understand exactly what these are… It seems like these are like starter spots. So if you have a specific kind of project – or what are these templates? Am I thinking about it right? You can just kind of use one of these to get started?

Yeah, absolutely. And I think you also really nailed another challenge, and something that I was kind of mentioning earlier, of “Hey, I don’t know where to get started with containers. Or like maybe I’ve heard feedback from other folks that they’re complex, confusing, time-consuming, compute-intensive… So is this something I want to invest in? Or should I? Is this where the community or the market’s going?”

So yeah, we really try to make it easier to get started with Dev containers, and to make it so that we’re really taking out complexity, where folks might have previously found complexity when doing containerized development… So yeah, with templates, we have a set that we host as part of the spec, so for a variety of different languages or scenarios, like Python, or even like base Ubuntu, or something like that. And so it’ll give you the Dev Container files necessary to kick off development for that kind of project. And from there, then you can totally customize it, like “Hey, I want to add other features. Or maybe I just want to add other settings or configuration that’s not in the feature”, and that’s totally okay. But we’re trying to just give folks those building blocks, so it doesn’t feel like “Hey, I’m starting from scratch, and that’s time-consuming, and that’s intimidating.” No, this can actually be a fun, and even kind of straightforward process.

Yeah, I think that’s gonna be key…

I was looking at one of the templates there… It’s the Elixir, Phoenix, Node, and Postgres, Jerod. Not MySQL Postgres, so…

Hey, that’s perfect. That’s us. We need all those things.

[45:35] It doesn’t look like ours, though. I mean, not that it has to be the same, but there’s obviously two different ways to roam… In this case, at least. So essentially what you’re saying, Brigit, is this template exists there. I could take the devcontainer.json and I can take the Docker Compose YAML file, essentially pull them into my project, or something like… I haven’t read the readme thoroughly, but I can essentially adopt this into my project, or start a brand new one from it, and have essentially the building blocks of what is our stack - Elixir, Phoenix… Node we’re not really using though; we’re using npm, of course, and different JavaScripty things… But Postgres, in that case. So that’s essentially the building blocks of the majority of what our application stack is.

Yep, for sure. And yeah, you can take it as inspiration, you could use it as your actual dev container, you can add things to it over time… And you’ll see as well, we also publish a set of images, so those are going to be referenced in like our templates, for instance… And so you can kind of extract any of the things that we’re publishing, and say “Maybe I can use some of this, all of this, take it as inspiration and go from there for configuring my environment.”

And essentially, you’re spinning up a Docker image if you’re doing local environment stuff. So if I’m doing this locally, this lets me set up a Docker image that has this environment baked into it; when it comes to using VS Code or a different text editor, whether it’s Vim or whatever, you have port forwarding for going into and out of the container, so that I can run the application… Let’s say it’s on port 4000, like any typical web application, and say like 5432 or whatever for the SSL version of the application. So that’s how that works. You spin up a container, your editor is still editing the code, but it’s inside… Is it inside that container, or is it just running it? How does that work? Break it down.

Yeah. So essentially, everything you’re doing is living in that container, you can view it as… So you could view it as kind of our model for remote development and VS Code in general; like, you’re really working in that remote environment, whether it is a dev container, whether it is the Windows subsystem for Linux, whether it is a remote VM or desktop machine via SSH, or tunneling. And so that way, you don’t have to copy code in and out, or back and forth, like you might have had to do in other environments, or worry about “Oh, I know my remote environment”, whether it’s a dev container, one of the other options; like, “I have this dependency I need, but now I need to redownload it locally.” It’s like, no, you can just develop completely within that remote environment.

And what’s cool with Dev Containers too is there’s a variety of ways that you can reference what you want to be set up or configured… So like you were saying, you could reference a Docker Compose .yaml, you could reference just a Docker file, you could reference just an image. It really depends on just like what you want to do, ir how you have your project set up. Are you pre-building images, so you could even have it where you’re like publishing what you made in your image, so that way you can use it then, and like devcontainer.json is later; you don’t have to redefine all that devcontainer.json stuff, and other people and other projects can use them, too… So there’s a ton of flexibility there, just depending on how your team works, and how you’re pre-building things, or are you all using Docker Compose .yaml.

So what happens whenever I spin that image down then? So if my code lives in there, my commits are in there, does this thing have the keys to my GitHub, essentially? How does that go one layer further? How am I building inside this container, and how is it ephemeral, can go away, but yet, I’m not losing my code? Like I’m five here…

So yeah, essentially with containers you have a couple of options, where either you can mount your source code into the containers, you can use a bind mount or you can use a volume… We have an option, for instance, in the Dev Containers extension where you can clone a repo into a volume. And so volumes are the recommended way to work with containers, because then essentially it’s like a little bit more optimized for how like Docker, for instance, is handling it… So it’s like a little bit more efficient as well. So there’s kind of a lot of things we can get into, like volume, bind mounts, all those things, but…

Sure.

…yeah, I don’t know if that’s helpful.

Well, I just think of like the resistance. I’ve gotta imagine part of the pushback is this confusion, I would say… So I’m asking you to clarify, because I think there’s a lot of – at least it’s confusing for me. So I would imagine if I’m typically – I’m Jerod; I love my local machine. I don’t mind dirtying it up, however it is… Elixir, Node, npm, install it all. I love it. Right?

[50:06] Oh, yeah. All things.

But then you go to the container, and it’s like “Well, where does my code live?” Sure, I understand volumes, and understand binding… And if I’m developing in that container, is the code in that container? Is it still in the local repository? Does it simply just run the mirror image version of it, and I’m still essentially git-committing to my directory right here on my box, and it’s not remote? …even though it’s Docker local, you consider it remote, based upon what you’ve just said there, right? Anytime it’s not your actual machine, and it’s an image, you’re saying remote.

Yeah. Right. And so yeah, if you have - like you mentioned, if I’m making commits, or something like that, they’re not gonna be like “Oh, these are just special commits that then got discarded outside of my container”, or something like that. It’s like, no, you can commit back to your GitHub repo, and your changes are still going to be there. And so that’s kind of the cool thing about having a dev container in a GitHub repo, for instance, is “Cool, yeah, and then if I open Codespaces, or I open anywhere else that’s supporting Dev Containers, I can just work on my code directly there, with also the tools that I need.”

How do the credentials work? So if I’m logged into github.com, I’m looking at an a repo, I opened it in a Codespace, now I’m logged into JerodSantoFictionalJourneyP775G6 etc.

Is that the URL?

Well, that’s part of the URL. It’s a fictional journey… It’s my current Codespace. And let’s say I’m just hacking along inside my Codespace, and I say, “Alright, I’m going to commit this code, I’m going to push it back to my repo.” How does it know it’s me? How are my security credentials injected into the Codespace? Do you know?

Yeah, so with Codespaces – so you can use Codespaces in the browser, or you could use a Codespaces extension in desktop VS Code. And either way, Codespaces is going to handle your GitHub off. So it’s up to the Codespaces extension or service to securely let you log in, and make sure that it’s really you logged in. So when you’re working on that Codespace in the browser, it’s tied to your GitHub account, so you can’t use a Codespace anonymously. At this point, it’s just going to be tied to you. So as long as you authenticated into github.com, or you authenticated into the extension, then you’re going to be offed and secure

Right. Speaking of that, are you 2FA to GitHub, Jerod?

I feel like you’re social-engineering me right now.

I mean, I want to know, because at this point you’re outing yourself to be maybe insecure, potentially. So get secure, if you’re not 2FA-ed.

I’m not going to answer that question.

Okay.

So if you are working locally in VS Code, inside a dev container, the code is in the container, right? And you mount it locally somehow, VS Code handles whatever dance that is, and then as long as it has local credentials for SSH, or however you’re authing against your remote origin, whether it’s GitHub or some other provider - as long as you have access to that in your local system, it’s just gonna pass that through, or use that directly. It should be pretty straightforward.

Yup. And you can use the same – like, if you’re using Git or GitHub commands via a terminal, or via extensions in VS Code, then you can install or use the same ones in your container, and get that same access and authentication.

Okay. It’s almost too good to be true, Adam.

Almost.

Too good to be true. Is it not true? Because usually, when it’s too good to be true, it’s not true. Going back to these templates… So I’m looking at the Go one now in the official Dev Containers Templates repo, the Go template… And there is no Docker Compose, there’s no Docker even in the template. It’s just like pointing at variants of an image. There’s no image URL that I can even see… Documentation URL, license URL, image variant… Does this have built into it knowledge of this default repository of images, perhaps? Because it looks like it’s going to be pulling from a Microsoft-hosted thing; imagemcr.microsoft.com/devcontainer/go, according to this.

[54:14] So I guess Microsoft is hosting a bunch of these images for people. And if you don’t specify anything, like a specific image URL or a Docker file that grabs an image itself, it’s just all falling back to Microsoft hosted stuff? Am I reading this right?

Yeah, so the set of templates that we host as part of the spec are all going to reference images that we’re also publishing as part of the spec. So if you go to github.com/devcontainers/templates or /images, you’ll be able to see the corresponding templates and images that we’re publishing. And in the templates, for instance the Go on that you pulled up - that image property is pointing to the Microsoft container registry, or MCR, which is where we’re publishing our first-party spec images, and we try to just make it simpler… If – hey, our templates just need to reference that image, so that way you don’t have to worry about “Oh, I need to manage additional files, or like know how to work with or add a Docker file.” But if you want to use a Docker file, or your project already has a Docker file, you can totally use that, too. You would just move that image property over to your Docker file, instead of in the devcontainer.json, and then have your devcontainer.json point over your Docker file.

Right. I love that; it’s sensible defaults. You’re actually providing a service here, right? Like, you’re providing an image repository that people can download images from, in the case that they don’t have their own, or pointing at Docker Hub, which is what many images currently hosted on Docker Hub or elsewhere… It makes the getting started for the simplest case pretty straightforward. If your code is just using Go 1.19 or 1.18, you can just take this template, drop it in your folder, devcontainer.json, maybe add a customization or two, maybe not… And you can have a dev container with Go installed, ready to run your code.

Yep, exactly.

I mean, who doesn’t want to have a Go machine one click away, essentially? I mean, that’s how you get there’s, is this. We just had that conversation with Matt, basically; we were talking about that though, we were just like saying how allergic we are to just rando installs to different things, and like… If I’m Go-curious, which a lot of the Go Time audience is - there’s a lot of people who were in the Go world, and they just don’t even mind; they drop things on their path, a Go binary, or whatever…

Yeah, it’s already set up. Yeah

But if you’re Go-curious, like “How does this work?”, you can just spin up a Go container via Dev Containers, play around, and your local machine is the same as it was when you closed that machine down, when you closed that container down. It’s right there… Which I think is super-cool. I just love the ephemeralness of it, but also the permanence in how the Dev Containers spec lets you specify so much to use it within teams and different organizations.

I guess the really interesting thing is when it goes beyond us nerds, right? We geek out on this stuff, right? This is great to us. But what about when my son, who’s seven, is at school, and he wants to go into this class, which he’s now in some G&T classes, and they’re doing computer things… Well, I don’t know if it’s that mature yet, but I’ve gotta imagine that the teacher isn’t going to want to have to set up every single machine and do all these different things for six or seven different computer environments that are all the same Go environment, for example. Let’s say they’re learning Go, or they’re learning Python as their first language. Wouldn’t Dev Containers be amazing in that scenario, where it’s just like “Well, if you have Docker installed, and you can borrow this template - which is pretty easy, you just copy it down…” Wow, that teacher, or whoever’s leading that class has just got a star next to their name, because they’ve got six machines up, running a Go space, or a Python space that a kid can play with, essentially, pretty quickly… Rather than the whole song and dance.

Yeah, I love that you brought that up too, because education is the space that we’ve really identified too that these could be super helpful in… Especially in some of the more cloud-powered or automated tools like Codespaces, or other ones. I don’t even have to like install anything locally, I can just go to the cloud and have everything that I need there.

[58:18] I think that’s an awesome opportunity in education, because we’ve gotten feedback from educators and students alike, that “Hey, at the beginning of a new semester I have to spend the first few days or weeks just getting everything I need for this class. And if I’m maybe studying computer science, I have a bunch of different dependencies that I need, across a bunch of different classes… So what if either my professor added a Dev Container, or us as a class, we had some Dev Container configuration that we could share?” So it’s like “Oh, don’t even worry about which version of Python do I need for this class or that class.” “Hey, no worries. It’s just in the Dev Container. Go grab it.”

That’s music to my ears.

For sure. It’s also roots from the original GitHub inception, which was permission to mess up. Like, this is the ultimate permission just to play, right? If I’m Go-curious and this Go container is one devcontainer.json away, Jerod, as you said before - that’s so cool! Just one devcontainer.json away… That’s so cool!

A semi-tangent - I’ve kind of played with this in a different world. I’ve been tinkering with Proxmox, and containers, and stuff like that, and I’m doing a lot of homelabby stuff… And I’ve been playing with TrueNAS, and other things, more so because Proxmox makes it so easy to spin up a brand new Ubuntu image, or a Debian image, or whatever I want to do… And it’s just a cool world out there, where it’s like the same thing, but in the developer environment space. And that to me is just so awesome, because you don’t have to figure out “How do I create a Go environment, or a Python environment?” I mean, you can, if you’re going out your own route and your own bespoke way. But like you had said, for the most part, you’ve got a lot of templates to get you started, or at least spark your curiosity to understand “How can this be leveraged?” It’s just that easy.

Yeah, absolutely. That’s what we’re hoping for, to make it just that easy.

[laughs]

Jerod is out here laughing. Come on, Jerod…

Well, Brigit, you turned us into salespeople for you. He’s like “It’s just that easy!” [laughter]

Yeah, I love it. Like, within an hour. I’m like “Oh, I don’t even have to be saying what are the pros there, or anything like that.”

We’re converted. We’re converts.

Thank you.

Brigit just sits back and lets us get excited about it. She’s like “Yes, we’ve got’em!” This is your adoption strategy, isn’t it?

It works…! [laughs]

This is good.

Yeah. You’ve just got to find the right podcasts…

Right. Let’s reel back and do our job of being good interviewers and say “What’s the downside?” What’s the cons? Where does it struggle? Help us get some balance back into this. We’ve been effusive for the last ten minutes, and we need to balance it out. What’s maybe left undone, or painful today, Brigit? Help us out.

I think that some of the next things we’re really thinking about is - we’ve made a lot of changes over the past year, from open sourcing the spec, and the CLI, to now moving to these new contribution models for templates, and features, and having indices for them, and all that kind of stuff… And with that, now that it feels like we have the major building blocks in place with the spec and the CLI, it’s like really getting more user feedback of, for instance, some of the questions you both have posed, of “Oh, okay, so it looks like the templates are just referencing an image.” Is that clear to folks? Because we hosted a previous set of Dev Container templates, we previously called them definitions, and those had Docker files in them. But we thought that as part of like the spec here was some simplification, and with these new images that we were publishing more publicly in this images repo, “Hey, let’s just reference an image there. It feels like that might be more straightforward.” But that may not be everyone’s scenario or expectation going in, especially for people who are already using Dev Containers, and more familiar with the old model, or the old repo.

[01:01:59.11] So I think getting feedback on some of those key choices that we’re starting to make… We’re really open to that feedback of “Hey, if this isn’t clear to users, we want to make it a good experience.” So we don’t want to say “Hey, well, too bad. We thought this was clearest and simplest, so you need to live with it.” No. That’s why we want to make it an open spec; like, what does the community think there, and sync with that.

And then - yeah, I think it’s cool too seeing the other kinds of like templates and features that folks contribute. For instance, is the contribution process clear for how I would publish? And is it clear that “Hey, I could totally choose to publish this for the whole community, or I could also leave this private just to me, or just to my company.” So getting feedback on those kinds of flows, and what we have built into the CLI, or into some of our other things that we offer. Like, we have GitHub Actions, or Azure DevOps tasks to kind of help with some of those processes. Like, are these things working well for users, or are there still some points to optimize? Because we’ll get feedback of “Hey, this command in the CLI wasn’t really documented.” And it’s because - oh, if we just added it, then we’ve got to make sure our docs are keeping up. So I think also just keeping like our docs going, and updating, and all that, since things are moving so fast, and making sure that then it’s clear to people as well, is something we’re always keeping in mind.

So this Go template we’re looking at, that’s been the example we’ve used here… So on line six, it references an image, what Jerod mentioned before… It’s an mcr.microsoft.com/ whatever URL, and it’s an image. So are you saying that – because one line above that it says “…or use a Docker file or Docker Compose file.” So essentially, you’ve removed the step, right? Is that what happened here? This newer version template uses an image you’ve already sort of pre-baked with would normally be in a Docker file.

Correct, yeah. And then if you go actually to the github.com/devcontainers/images, then you can see what’s contained in that Go image. And you’ll see “Okay, there’s the actual Docker file.” So ultimately, there is one; we’re just saying, “Hey, maybe it’ll be clearer, or less cluttery if we don’t have it there.”

And we also added that comment that you saw there in line five, “…or use a Docker file or Docker Compose”, after we’d gotten some feedback of “Hey, how can I use a Docker file?” Or “Hey, I used to know there were Docker files in your templates, but I’m not seeing them anymore.” So it’s cool that you saw that comment there, and we’re hoping things like that can help users… But seeing how we want to move forward with certain things like that.

Yeah. Magic is good once you’ve – it’s a graduate-into. Magic is good, I guess, out the gate, but for the most part, your kind of primary target audience, at least right now, wants to know all the lines. “Let me compose that Docker file for myself. Or at least tell me –” Maybe there’s two variants of this .json file, where you’ve got like the full feature one, which doesn’t reference the image, and the opposite one, which was before the image was created, essentially. Give me both versions, so that way if I’m – especially as you’re sort of training-wheels-ing people into this world, it’s like, “Well, you can go this simple if you’ve already pre-baked your images, or you can do the full thing, Docker file, Docker Compose and all, to get to the end result if you’re familiar with that.” Because I would imagine a lot of people are pretty familiar with Docker and Docker Compose to get to that world… But like Jerod even, with line six, it kind of stumbled him and he was like “Well, what’s happening here? Is there an image you’re hosting somewhere?” And as you’d mentioned, your reasons why. It makes sense, but I think if these are templates, and they’re meant to be initial exposure to how this works… Like, “I want to write this myself”, would it be this simple? Probably not. I would probably reference similar to the way I would bake a Docker Compose file now, which is an image somewhere else, and do all the different steps, that kind of thing.

[01:05:37.29] Anything left unsaid, Brigit? Anything you’ve been waiting for us to ask you, and we just haven’t got around to it, because we’re adults? Or have we covered it all?

We covered all the key parts, from - yeah, talking about what containers are, the open spec, of you getting excited about it and becoming endorsers for us here… [laughter] So we’ve really come full circle.

I’m gonna put these sound bites on the homepage, and really get people using it.

Yeah, for sure. What’s a good first step, if we’re giving the audience – maybe they’ve started out like us, apprehensive at first, and curious, and learning, and asking questions, and now we’re sales folks for the Dev Containers spec now (that’s Jerod and I), what about our listeners? So if they’re new to this, they’re like “Okay, what’s a good first step?” Where do you tell people to go? Obviously, DevContainers.dev, but what’s a good first step for someone to do? Would you say a template, or what would be a first try for someone?

Yeah, I would say in an editor environment of your choosing… We talked about VS Code and Codespaces a lot, so those are great ones to start out with… Just try out adding a dev container, and building within it, and seeing “Hey, okay, how does my interface look compared to what I’m used to locally?” So we have commands for you to add Dev Container configuration files; that should walk you through the necessary steps, and having those files in there… And then kind of getting used to “Okay, yeah, then I’ll just reopen in my container. And then if I make a change to the configuration, I’ll just make sure that I remember to rebuild.”

Once you get up and running with it, just a couple of steps or commands there, it should hopefully be pretty straightforward, and then from there you can become even more productive in them. So I recommend checking out - with containers.dev you can kind of get an overview of the things that we talked about today, and then also on our supporting tools page on there you can see “Oh, cool, here’s where I can learn more about using it in VS Code, or Codespaces. Or here’s how I could use it in maybe some of these other tools that I’m already using.”

Yeah, I messed up there. I said devcontainers.dev. Sorry about that.

No worries.

Containers.dev, for posterity and clarification’s sake. Containers.dev… Just kidding. I had to say it real loud… [laughter]

Say it five times real fast.

Ah…! Maintainer, maintainer, maintainer. Brigit, it’s been awesome. Thank you so much for joining us and taking us into this new world. We’re going to explore it a bit ourselves, and encourage those who we see to do so as well. Thank you for coming on the show. We appreciate you.

Yeah, totally.

It sounds great. Thank you so much.