[HN Gopher] Codespaces but open-source, client-only, and unopini...
___________________________________________________________________
Codespaces but open-source, client-only, and unopinionated
Author : el_hacker
Score : 329 points
Date : 2023-06-20 17:30 UTC (5 hours ago)
(HTM) web link (devpod.sh)
(TXT) w3m dump (devpod.sh)
| muunbo wrote:
| Really cool! Is this intended for individual users or for keeping
| dev environment in sync across teams of people?
| gentele wrote:
| That's correct. It uses the .devcontainer.json standard to
| define everything as code and it abstracts the cloud/infra and
| allows for an easy way to spin up a dev environment with a
| .devcontainer.json in any infra
| michaelmior wrote:
| Looks interesting but unfortunately neither the deb or AppImage
| options worked for me on Ubuntu 20.04. (Yes, I probably should
| upgrade.)
| gentele wrote:
| Will definitely look into this. Thanks for reporting this!
| agrippanux wrote:
| Same here
| lastangryman wrote:
| 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?
| CGamesPlay wrote:
| 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.
| highmastdon wrote:
| 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...?
| CGamesPlay wrote:
| The first problem you'll encounter here is if you're using
| a language that keeps dependencies in a separate place
| (virtualenv, central cache location, etc.). You have to
| figure out how that works and mount that location as a
| separate volume, or else you'll be constantly recompiling
| everything when your container is recreated. Using a bind
| mount for the project files is also annoying because
| docker-compose makes no effort to sync your uid/gid, so you
| have all sorts of annoying permissions issues between
| local/container. And installing packages into your
| container that doesn't have an init process is... annoying
| at best. You can use sysbox to get one, but you're not
| really "just using docker compose" at that point.
| PrivateButts wrote:
| 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.
| KronisLV wrote:
| > 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/eve
| rything%20is%20broken/containers-...
|
| But for what it's worth, at least they're trying and are okay
| for the most part otherwise.
| inglor wrote:
| > How often is this actually necessary?
|
| Think "I have several teams and the output of 'team a' is a
| dependency of 'team b'" and 'team a' needs to release twice
| a day".
| KronisLV wrote:
| > ...and 'team a' needs to release twice a day"
|
| That's quite the fast paced environment! In that case the
| shortcoming seems like a valid pain point, provided that
| you need to launch everything locally with debugging
| (e.g. breakpoints/instrumentation) vs just downloading a
| new container version and running it.
| gigel82 wrote:
| I really envy folks working on backend / web stuff when I see
| these kind of things. Stuck building client apps on desktop and
| mobile, the options are slim (full VMs, slowness, etc.)
| karl_gluck wrote:
| Same. I started building an automated solution for building
| gamedev environments in VM's[1] but I can't help but think
| there should be a better way.
|
| [1] https://github.com/karlgluck/swiss-chocolatey-lab
| Smaug123 wrote:
| > 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"?
| earthling8118 wrote:
| Well you see if they acknowledged nix then they wouldn't be
| able to claim to be the first.
| gentele wrote:
| Haha, spicy. We definitely don't want to overlook nix. It's a
| great tool. We do mean something different with "developer
| environment" in that context of this quoted sentence. I'm not
| sure if nix will help you much if you want to connect your VS
| Code to a remote VM or container to work inside of that
| environment. We'll work on rewording this though to make
| things clearer :)
| Smaug123 wrote:
| "Containerised" would be less ambiguous, I think.
| gentele wrote:
| Oh yeah, that would make it clearer! Thanks
| jchannon wrote:
| Does it work on iPad?
| gentele wrote:
| No(t yet)
| CGamesPlay wrote:
| 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
| Yeroc wrote:
| I suppose Eclipse Che <https://www.eclipse.org/che/> would also
| count?
| twobitshifter wrote:
| Microsoft has DevBox but it's not clear where that fits around
| Codespaces?
|
| https://techcommunity.microsoft.com/t5/azure-developer-commu...
| 22c wrote:
| 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/
| __MatrixMan__ wrote:
| 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.
| 22c wrote:
| 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.
| bryanlarsen wrote:
| devbox is a similar idea, but is more approachable for
| those who don't know nix.
| evantbyrne wrote:
| Vagrant was fantastic pre-Docker and is still arguably more
| useful for certain cases, but I recall having issues running
| it last I tried. Based on the website, VirtualBox still lacks
| stable ARM64 support. Would "boxes" downloaded from the
| Vagrant cloud need to be built for ARM64 as well, or does it
| emulate?
| dharmab wrote:
| It does not emulate. My org has been deprecating Vagrant
| ever since IT started issuing Apple Silicon as an option.
| Replacement is Docker Compose, or cloud VMs for software
| with heavy disk I/O.
| pcthrowaway wrote:
| Do you know if Packer is still decent for building cloud
| AMIs? Or do you have any suggestion for building custom
| images that can run on cloud platforms as well as
| locally?
| debosmit wrote:
| https://devzero.io
| luckywatcher wrote:
| It's not a direct competitor, but we use https://tilt.dev/ at
| my company for local and remote development.
| foxtrotwhiskey9 wrote:
| I think StackBlitz (https://stackblitz.com/) falls into this
| space
| CompuIves wrote:
| At CodeSandbox (https://codesandbox.io) we're also working on
| this! Main focus of us is that we're running the environment in
| Firecracker microVMs, which allows us to snapshot and clone
| environments very quickly. This enables us to create a VM for
| every branch, which comes with the added advantage that every
| branch automatically has a snapshotted preview environment that
| can resume in ~2 seconds.
| nkko wrote:
| https://www.daytona.io is currently in stealth preparing to
| launch. You could grab early access by joining the waitlist.
| esafak wrote:
| What's its difference?
| ammario wrote:
| Coder's big difference is that it uses Terraform for
| provisioning, so it can do Docker/Kubernetes as well as VMs
| brazzledazzle wrote:
| AWS has Cloud9[1] though it's worth pointing out that it's not
| an exact a 1:1 and may require some elbow grease to use in the
| same manner[2].
|
| 1. https://aws.amazon.com/cloud9/
|
| 2. https://aws.amazon.com/blogs/architecture/field-notes-use-
| aw... (2021)
| jchw wrote:
| There's also koding.com, which has been around for a while. I
| tried the service quite a long time ago because I used to find
| the "cloud coding" concept enticing, though it was definitely
| not as baked (probably due to Monaco not existing at the time,
| and likewise, browsers not being as good.) Nowadays I still
| feel like the user experience problems, limitations, and cost
| (when not subsidized) with coding this way largely make it a
| niche for people who have unusual needs. Especially because,
| there are tons of local options for reproducible dev
| environments, and they can continue to work without a network
| connection or on unreliable connections, something that is
| unimpressive even in the best conditions I've seen so far.
|
| If you happen to have the exact set of needs that one of these
| products solve, then it can probably work fairly well. But,
| even when working on "web" stuff, I always find myself feeling
| like they're just never quite as good as just doing things
| locally. I feel like devcontainers and cloud coding in general
| are more impressive to those who haven't managed to tame their
| own dev environments and are seeing a solution to this for the
| first time.
|
| It's also clearly useful for people on iPads and other devices
| that are either too low end to run/compile your code or
| arbitrarily limited to prevent it. However, with how powerful
| iPads are nowadays, it feels like if Apple ever allowed apps to
| use virtualization extensions, it would probably be a better
| solution for a lot of people who do not need a huge cloud
| workstation with a lot of RAM. I imagine your average Rails app
| or Go backend would just have no problem running directly on an
| iPad.
| 0xbadcafebee wrote:
| Bridge to K8s, CloudShell Editor, Cloud Code, Coder, DevSpace,
| Eclipse Che, Garden, GitPod, GitHub Codespaces, ksync, Kubectl-
| warp, Nocalhost, Okteto, Squash, Stern, Skaffold, Telepresence,
| Tilt
| nvartolomei wrote:
| https://hocus.dev/
| andrewmunsell wrote:
| 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 support this at the
| moment
| numbsafari wrote:
| Will they ever? JB isn't really known for doing that sort of
| thing.
| sandGorgon wrote:
| +1 on this. something like openvscode integrated would be
| awesome
| gentele wrote:
| 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.
| solarkraft wrote:
| > Mac (Silicon)
|
| Huh? Yes, it contains silicon.
| weikju wrote:
| Short for "Apple Silicon", the marketing name for Apple's own
| series of ARM CPUs used in Macs since 2020.
| [deleted]
| drewtato wrote:
| This is like shortening github to git
| pmeira wrote:
| Not only that, when using Firefox (Chrome seems fine), it's
| selected by default on Windows and Linux.
| 0xbadcafebee wrote:
| I'm glad this space is expanding. This is created by the authors
| of Loft.sh and Devspaces, both really great solutions to the most
| common problems of developing natively in a K8s cluster.
|
| DevPod is basically Vagrant but with containers, which brings a
| ton of benefits over the former VM-centric design. You can
| maintain an entire team (or organization) with one immutable
| development environment, to get away from the constant toil of
| fixing random problems on random people's dev environments that
| happened because they changed something locally and don't have an
| immutable environment to restore.
|
| The fact that it's self-hosted means you can take it anywhere
| (your laptop, GCloud, AWS, Azure, etc). Containers means you can
| save resources or scale it, reuse public containers and container
| ecosystem tools. Unopinionated means you aren't forced to use one
| IDE or platform. Open Source means you can read the source to
| figure out what's going on and hack in a solution if needed.
|
| This one is still early days it seems, as it doesn't run on my
| Mac (I opened an issue). But the benefits once it works will be
| incredible. I've been trying to onboard our teams to Devspace,
| which has its warts [and lack of docs], but is still lightyears
| better than most other solutions. Once DevPod is stable I'll be
| looking into moving to it.
| gentele wrote:
| Thanks for opening an issue! We'll definitely look into that.
| Would love to learn more about your experiences with DevSpace
| as well. If you're open to chatting, reach out via slack or via
| lukas [at] loft [dot] sh
| whimsicalism wrote:
| I think this looks awesome - exactly the piece that I feel like
| has been missing from setting up a remote instance for vscode,
| simple app for provisioning the instances.
| donmcronald wrote:
| I looked at this about a week ago and think it has potential. One
| thing I dislike, and it's an industry wide problem, is the
| eagerness to continuously (re)build containers on demand [1].
|
| Everyone does it, but I think that's a mistake. What I want is
| something where I can build and publish a dev container to my
| local Docker registry and then use that container to develop
| until I decide I need to build an updated version due to changes
| in the OS, dependencies, etc..
|
| To help clarify, look at this picture [2]. I'd want everything up
| to dependencies or resources, plus all of the tooling needed to
| make the Jetbrains Gateway, etc. work in the dev container. I
| want to build that container on a calendar based schedule (ex:
| daily) and have everything I need to develop accessible via local
| repositories that I can use without connecting to the internet.
|
| Long ago I came to the conclusion that most Docker builds aren't
| repeatable, so the idea of re-building a consistent environment
| seems naive. For example: RUN apt-get update &&
| apt-get install vim
|
| Without specifying the exact version of every dependency, you
| won't be guaranteed the same version of 'vim' every time. Plus,
| even if you specify the exact version of your direct
| dependencies, I think you can still end up with varying
| transitive dependency versions. Even just the 'apt-get update'
| portion of that command is often misunderstood since it can
| return 0 as a result of transient failure.
|
| So, even if your intent is to build a container with the most up-
| to-date versions of everything, a transient failure between the
| update and install commands can leave you with ancient versions
| of dependencies, even if you intended everything to be up-to-
| date. This is especially true if you're using a local APT cache
| like Sonatype Nexus where the upstream 'update' might fail and
| the local cache probably has old versions of all the
| dependencies, allowing the install command to succeed.
|
| IMO it's better just to assume you have zero guarantees when
| (re)building Docker images and you're better off adopting a
| strategy of build, publish, use.
|
| 1. https://devpod.sh/docs/developing-in-
| workspaces/devcontainer...
|
| 2. https://phauer.com/2019/no-fat-jar-in-docker-image/#the-
| solu...
| j1elo wrote:
| > _Even just the 'apt-get update' portion of that command is
| often misunderstood since it can return 0 as a result of
| transient failure._
|
| Tiny correction that got me confused: an exit code of '0' would
| actually mean 'success', so you probably just meant that it
| could fail at any moment.
|
| But also, this can happen any time external servers are
| accessed, regardless of the tool. An npm install could fail any
| time without warning, if the servers are down. Devs should
| expect their supply chain to break sooner or later, and plan
| accordingly depending on the severity of the consequences.
|
| My example is if you use the Ubuntu debug packages repository,
| you'll basically never know if the next run will work until
| 'apt-get update' is run. Those repos are seemingly down or
| 'reindexing' for hours every few days.
| donmcronald wrote:
| > Tiny correction that got me confused: an exit code of '0'
| would actually mean 'success', so you probably just meant
| that it could fail at any moment.
|
| No. It fails and then returns 0 = success. It's a design
| choice. [1] [2]
|
| > But also, this can happen any time external servers are
| accessed, regardless of the tool. An npm install could fail
| any time without warning, if the servers are down.
|
| I think that strengthens my argument that everything should
| be baked in to the dev container.
|
| Edit: Reviewing those bugs, I see there's a new option to
| control the behavior: -eany, --error-on=any
| Fail the update command if any error occured, even a
| transient one.
|
| 1. https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1693900
|
| 2. https://bugs.debian.org/cgi-
| bin/bugreport.cgi?bug=776152#15
| qudat wrote:
| Have you looked into distrobox? I'm using it now for my dev
| environment running on top of an immutable OS (microos).
|
| It's not perfect but I never have to spin the container down.
| timmytokyo wrote:
| Tried it, but it doesn't seem to work with non-rootless podman as
| a replacement for docker.
| esafak wrote:
| Are you using podman for everything in production? I am still
| trying to understand when to use it.
| timmytokyo wrote:
| I don't have any experience using podman in production. I use
| it on my dev PC for work, where I have to run Windows.
| Previously I used Docker Desktop for Windows, but I got tired
| of dealing with its various annoyances. Podman has been a
| mostly seamless drop-in replacement. It doesn't support
| swarm, which I used to use with docker, but I've found a good
| solution using docker-compose instead.
| gentele wrote:
| 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?
| donutshop wrote:
| Unopinionated*
| love2read wrote:
| My immediate thought is the design isn't there yet. Maybe the
| tool is but people also pick tools based on how they look, and
| this could take a facelift before mass marketed.
| mynameisvlad wrote:
| What isn't there yet about the design? It seems like a standard
| flat modern tool to me from the screenshots in their docs.
| birdiesanders wrote:
| So cool to see products pop up with support for Civo, I've been
| with them from day one and it's a good feeling having a Civo
| button in that program.
| gentele wrote:
| Civo is great!
| [deleted]
| shever73 wrote:
| I'll pop into Slack tomorrow to see if anyone can help me get it
| up and running. Using both the CLI and the GUI on Mac silicon
| with AWS, I haven't been able to get a single instance working.
|
| Even just an empty folder!
___________________________________________________________________
(page generated 2023-06-20 23:00 UTC)