Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Codespaces but open-source, client-only, and unopinionated

devpod.sh

Post reply on HN
Print view View original

21–30 of 157 posts

Re: Codespaces but open-source, client-only, and unopinionated

#21

Post by gentele »

andrewmunsell wrote: post #7

I'm likely not the target audience, but I personally see "client-only" as a disadvantage. Ultimately I use VS Code to stand up devcontainers on my laptop, but I sometimes need to do dev work on my iPad and don't want to pay for Github Codespaces. Gitpod has worked for me in the past and I've gotten Coder setup. Maybe this will be nice to get Jetbrains IDEs working with the devcontainer standard, since IIRC they don't…

Don't worry. We'll be adding a server-side option for DevPod Desktop app to connect to for enabling thin-client/browser-based work but the cool thing is that this is not a requirement to use DevPod. It's more like Terraform and Terraform Cloud. You can run with Terraform and use it entirely client-only but you can also have server-side solution on top for specific things that just need central management.

Re: Codespaces but open-source, client-only, and unopinionated

#22

Post by __MatrixMan__ »

22c wrote: post #14
CGamesPlay wrote: post #9

What are some of the competitors in this space? - Gitpod, a SaaS competitor to Codespaces. http://gitpod.io - Coder, which I guess is the more enterprisey self-hosted Codespaces alternative? https://coder.com - This project, Devpod, seems to be a polished experience but not centralized like Coder. - I recently stumbled upon Recode, which looks like a more indie take on the problem. https://github.com/recode-sh/cli

It's a lot older but I would say Vagrant intersects with this space https://github.com/hashicorp/vagrant Possibly devenv, as well.. Though I haven't personally tried it https://devenv.sh/

I've been using devenv for new projects. I like it so far. Some might find nix (which it requires) to be overkill, but I think that's underestimating how devilish of a problem it's solving.

Re: Codespaces but open-source, client-only, and unopinionated

#25

Post by 22c »

__MatrixMan__ wrote: post #22
22c wrote: post #14

Earlier quoted context omitted.

It's a lot older but I would say Vagrant intersects with this space https://github.com/hashicorp/vagrant Possibly devenv, as well.. Though I haven't personally tried it https://devenv.sh/

I've been using devenv for new projects. I like it so far. Some might find nix (which it requires) to be overkill, but I think that's underestimating how devilish of a problem it's solving.

It seems more approachable than going down the NixOS rabbit hole.

I haven't had a need to reach for it yet, but I will probably try it out at some point.

Re: Codespaces but open-source, client-only, and unopinionated

#26

Post by gentele »

timmytokyo wrote: post #24

Tried it, but it doesn't seem to work with non-rootless podman as a replacement for docker.

Thanks for trying it! Can you open an issue on GH about this or join us on slack, so we can dig deeper into making this work for non-root podman with your input?

Re: Codespaces but open-source, client-only, and unopinionated

#27

Post by earthling8118 »

Smaug123 wrote: post #15

> DevPod is the first and only tool for creating and managing dev environments that does not require a heavyweight server-side setup. I guess either "dev environment" means something different to what I understand by the term, or Nixpkgs is considered a "heavyweight server-side setup"?

Well you see if they acknowledged nix then they wouldn't be able to claim to be the first.

Re: Codespaces but open-source, client-only, and unopinionated

#28

Post by bryanlarsen »

__MatrixMan__ wrote: post #22
22c wrote: post #14

Earlier quoted context omitted.

It's a lot older but I would say Vagrant intersects with this space https://github.com/hashicorp/vagrant Possibly devenv, as well.. Though I haven't personally tried it https://devenv.sh/

I've been using devenv for new projects. I like it so far. Some might find nix (which it requires) to be overkill, but I think that's underestimating how devilish of a problem it's solving.

devbox is a similar idea, but is more approachable for those who don't know nix.

Re: Codespaces but open-source, client-only, and unopinionated

#29

Post by PrivateButts »

highmastdon wrote: post #12
CGamesPlay wrote: post #8

Earlier quoted context omitted.

Docker compose is a pretty poor development environment experience. Constantly having to rebuild containers to recompile dependencies; dealing with permissions differences for volume mounts; having to modify all the scripts to start with "docker compose run --rm"; having to deal with no shell history or dot files in the application containers... it leaves a lot to be desired.

Is it really like that? I expected a docker container having all the deps except for running the project which would be something that’s mounted as a volume. Then each container would spin up its own watcher to build/test/serve the project. And have a bash open to run additional commands. Maybe my assumptions are wrong though…?

That's the dream, but in my experience there are some thorns, and some things that just suck. Mostly these come from Windows, like a dev station using the wrong line endings, filesystem watchers not working if the project isn't on WSL storage, file permissions getting mucked up, etc. However, what is a pain in the butt is adding dependencies. Do you attach a shell and run npm in the container or try to do it on the host system. Do it in the container, and you'll have to make sure those changes make it's way back out, and that you rebuild the container the next time you launch it. Do it on the host, and you could run into cross platform issues if a package isn't supported on Windows, and you'll have to rebuild the container.

However, once you're aware of this, honestly it's not that big of a deal. Docker rebuilds are pretty fast nowadays, and you can use tools like just to make the DX a little easier by adding macros to run stuff in a container.

End of the day though, folks are all gonna have their own way of working, and I think dev containers could have an advantage for peeps doing remote development. It would be nice to have a system where our developers could dial in to a container with everything they need from anywhere they want to work.

Re: Codespaces but open-source, client-only, and unopinionated

#30

Post by KronisLV »

CGamesPlay wrote: post #8
lastangryman wrote: post #5

Apologies, I'm not up to date in this space, so probably a stupid question but how does this differ to docker compose? My understanding of the value of codespaces was instant start up, literally zero to download locally, and centralised definition. Does this mean I would go back to have to downloading everything locally, albeit in a nice sandboxed package with a neat definition language and convenient command?

Docker compose is a pretty poor development environment experience. Constantly having to rebuild containers to recompile dependencies; dealing with permissions differences for volume mounts; having to modify all the scripts to start with "docker compose run --rm"; having to deal with no shell history or dot files in the application containers... it leaves a lot to be desired.

> Constantly having to rebuild containers to recompile dependencies;

How often is this actually necessary? I've had projects that stick with the same dependencies for weeks/months and don't need anything new added outside of periodic version updates. There, most of the changes were the actual code, that was needed for shipping business functionality.

Furthermore, with layer caching, re-building isn't always a very big issue, though I'll admit that the slowness can definitely be problematic! Except for the fact that you don't have to pollute your local workstation with random packages/runtimes (that might conflict with packages for other projects, depending on the technologies you use and what is installed on a per project basis or globally), and the fact that you get mostly reproducible environments quite easily - both of those are great, at least when it works!

> ...dealing with permissions differences for volume mounts;

This is definitely a big mess, even worse if you need to run Windows on your workstation for whatever reason, as opposed to a Linux distro (though I guess WSL can help). I personally ran into bunches of issues when mounting files, that more or less shattered the illusion of containers solving the dev environment problem sufficiently: https://blog.kronis.dev/everything%20is%20broken/containers-...

But for what it's worth, at least they're trying and are okay for the most part otherwise.

Post reply on HN