Looks like a nix-env clone, cool nonetheless
Codespaces but open-source, client-only, and unopinionated
111–120 of 157 posts
Re: Codespaces but open-source, client-only, and unopinionated
#112Local first, cloud optional is the only way (IMHO) we're going to get people off their local laptop development setups. We need to support local dev environments first, with the exact same config a developer can then move to the cloud. See https://github.com/jetpack-io/devbox for how this can be achieved and https://www.mikenikles.com/blog/dev-environments-in-the-clou... for my thoughts after 3 years of working in th…
Cloud dev envs do not require millisecond latency. Typing is done locally. Latency only comes in at the times like when you go to open up a new file which isn't locally cached on your machine. Having to wait 200 ms for a file to open isn't so bad.
Re: Codespaces but open-source, client-only, and unopinionated
#113There is zero text on the webpage on what this actually is, except that it's like Codespaces. Is Codespaces a household word nowadays? I had to look it up.
Re: Codespaces but open-source, client-only, and unopinionated
#114Local first, cloud optional is the only way (IMHO) we're going to get people off their local laptop development setups. We need to support local dev environments first, with the exact same config a developer can then move to the cloud. See https://github.com/jetpack-io/devbox for how this can be achieved and https://www.mikenikles.com/blog/dev-environments-in-the-clou... for my thoughts after 3 years of working in th…
Cloud dev envs do not require millisecond latency. Typing is done locally. Latency only comes in at the times like when you go to open up a new file which isn't locally cached on your machine. Having to wait 200 ms for a file to open isn't so bad.
IMO it's not about latency but consistency -- when I'm in flow, I need my tools working right now, without interruption
Re: Codespaces but open-source, client-only, and unopinionated
#115Earlier 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/
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?
Although it's the most common option, VirtualBox isn't the only supported hypervisor [1]. Maybe it will work with another one.
Re: Codespaces but open-source, client-only, and unopinionated
#116I haven't used Codespaces, but how does this work with databases? A common problem we have during onboarding is getting your local database (MySQL) setup properly: run all the migrations => load some sample, de-identified, production-like data => update certain rows to allow for personal development (e.g. for our texting service, make sure you text your own phone number, instead of someone else's). What's the workflo…
We've built www.snaplet.dev to introduce the exact workflow that you're describing. Unfortunately we're PostgreSQL only at the moment.
We give you a serverless PostgreSQL database per branch in your code. [via Neon.tech] Each time you branch your code we grab the latest snapshot of your production database which is de-identified and transformed [Transformations are via TypeScript] and a subset of the original.
If a coworker and yourself are coding against the same branch you're coding against the same database.
Your devs only run a single command `snaplet dev` and all this happens automatically in the background.
Re: Codespaces but open-source, client-only, and unopinionated
#117That's looking great! We're already experimenting with DevSpaces as our primary goal for the development process. What would you say are the main differences between devpod and DevSpace. Do they compliment each other? Should devpod at one time in the future displace DevSpace? Would love to get your view on that.
Re: Codespaces but open-source, client-only, and unopinionated
#118Earlier quoted context omitted.
Toolbox is not a developer environment, but rather a tool to provide 'a toolbox' to a container host, like the older Atomic, or CoreOS releases that are immutable. Dsitrobox is close to toolbox, but also not similar in providing a coder setup.
Toolbox seems pretty well suited for a console based development setup. It works as a simple wrapper around docker/podman which lets you build your dev environments using Dockerfile syntax which is very nice.
It is not really what DevPod provides as they connect a code-server, jetbrains, remote vscode, etc. Sure, 'Toolbx' can do that to; you can install vim, etc. We advertise toolbox as "interactive command line environments on Linux" foremost. DevPod offers this on Windows, MacOS, beyond the command line. as you said, it is just a wrapper around a 'special' (custom images can cause issues) toolbox container and podman. The tool they offer is much more streamlined to use providers; targeting different environments. Note: Member of the 'containers' group on GitHub/Red Hat.
Re: Codespaces but open-source, client-only, and unopinionated
#119What 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
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.
Love CSB. Using this a lot for quick setup of developer environments to test a code change, etc.
Re: Codespaces but open-source, client-only, and unopinionated
#120That's looking great! We're already experimenting with DevSpaces as our primary goal for the development process. What would you say are the main differences between devpod and DevSpace. Do they compliment each other? Should devpod at one time in the future displace DevSpace? Would love to get your view on that.
Yep, as we see it they compliment each other quite well. DevPod takes your workspace to the cloud and DevSpace let's you develop against your Kubernetes cluster - potentially the same one you used to start your workspace.
Internally we use both in our development setup, spinning up remote workspaces using DevPod, installing DevSpace and kind into the devcontainer, then using DevSpace to develop against the cluster. See the vcluster setup[1] as an example
[1]https://github.com/loft-sh/vcluster/tree/main/.devcontainer