Reminds me a bit of Dock [0].
Show HN: Devbox – Easy, predictable shells and containers
61–70 of 196 posts
Re: Show HN: Devbox – Easy, predictable shells and containers
#62Earlier quoted context omitted.
It's likely you have not installed the pre-requisites: namely nix. Without nix, it can't find the package. That said, we'll improve the error message so that when nix is not installed it tells you you should install it.
As far as I can tell it is: 05:10:27 $ nix --version nix (Nix) 2.6.0 I installed it with `apt install nix-bin` on Ubuntu 22.04. EDIT: I installed Nix with the old-fashioned "pipe shit to bash" method and it seems to work now. When I say "work", I mean it in the sense of "doesn't fail", because it's been stuck at `devbox shell` for a good five minutes now with no indication. Not to be too negative, I think this is a g…
The initial shell is slow: nix reinstalls a bunch of stuff the first time it runs. We’re planning to add a progress bar that makes that clear.
Sorry for the hiccups – it is our first pre release version but feedback like yours helps us harden it. It should definitely be considered beta software right now, but we’ll have it hardened before announcing a GA/1.0 version
Re: Show HN: Devbox – Easy, predictable shells and containers
#63Earlier quoted context omitted.
As far as I can tell it is: 05:10:27 $ nix --version nix (Nix) 2.6.0 I installed it with `apt install nix-bin` on Ubuntu 22.04. EDIT: I installed Nix with the old-fashioned "pipe shit to bash" method and it seems to work now. When I say "work", I mean it in the sense of "doesn't fail", because it's been stuck at `devbox shell` for a good five minutes now with no indication. Not to be too negative, I think this is a g…
The initial shell is slow: nix reinstalls a bunch of stuff the first time it runs. We’re planning to add a progress bar that makes that clear. Sorry for the hiccups – it is our first pre release version but feedback like yours helps us harden it. It should definitely be considered beta software right now, but we’ll have it hardened before announcing a GA/1.0 version
No problem! I suspected as much about the download, a progress bar would be excellent though. Overall, this is a fantastic idea, and I definitely see myself switching to it basically immediately.
Re: Show HN: Devbox – Easy, predictable shells and containers
#64This seems like a way simpler workflow than maintaining dockerfiles. I'm interested to try this out.
Re: Show HN: Devbox – Easy, predictable shells and containers
#65Earlier quoted context omitted.
I dunno, man. Some "dev ops" jerk at work is always complaining about how he has to spend all his time answering support requests from developers with errors in their local environment. It only takes like a couple hours of my week, so what? And then when our deploys fail because the server didn't have the same version of python as our local environment, he tries to blame the fact that the local and remote environment…
That sounds like a problem that can be solved with a CI/CD system and Docker Compose. Perhaps there is more going on here institutionally that stops this problem from being solved. It sounds like something really frustrating is going on though, and I hope it works out.
Hey I'd like to expand on this a little bit. I hope I'm not presuming too much but as someone who recently had to leave their job due to burnout, I feel like I'm seeing signs of burnout here, and wanted to bring them to your attention.
You sound really frustrated because you're being asked to do things that you feel aren't or shouldn't be part of your job, and perhaps it's taking time from your other responsibilities and creating a larger workload for you. It seems like maybe you've come to resent your coworkers and their individual preferences for the complexity it creates and the stress it causes you. It seems like what you want to do is erase that complexity, take away their agency, and centralize on a solution that works well for you.
There's a couple of things to consider. For one, what you're asking is for your coworkers to have a degraded work experience so that your work experience can be better, which is totally understandable but not reasonable.
Another one is that this is a pretty well understood problem with known solutions - why is it you can't get them implemented? Is there something going on in the politics or culture of your workplace that is stopping you? Is there some kind of elephant in the room, and would things get better if you called it out?
The last one is, are you getting burned out? Were you always this frustrated? Should you take some time off? Should you start looking for other jobs?
I can really feel the stress and frustration in your tone, and that sucks. I hope things get better for you.
Re: Show HN: Devbox – Easy, predictable shells and containers
#66@dloreto @robrich A little aside from the announcement, but since it seems like you both work on this I wanted to surface something that came up down in a subthread: I'm curious if you attempted to support macOS by doing this with Nix's dockerTools and cross-compiling (there may be better sources, but it's at least hinted at in https://nix.dev/tutorials/building-and-running-docker-images... )? If so, I'm wondering wh…
Haven’t tried that yet. We started with using Docker directly because we were very familiar with it, and thought users might want to “preview” a dockerfile before asking devbox to build a container (we don’t have that yet, but can easily add it)
That said, I do want to experiment with building the container directly through nix and seeing if there’s advantages to doing that. I just haven’t had the time yet.
Re: Show HN: Devbox – Easy, predictable shells and containers
#67@dloreto @robrich A little aside from the announcement, but since it seems like you both work on this I wanted to surface something that came up down in a subthread: I'm curious if you attempted to support macOS by doing this with Nix's dockerTools and cross-compiling (there may be better sources, but it's at least hinted at in https://nix.dev/tutorials/building-and-running-docker-images... )? If so, I'm wondering wh…
Haven’t tried that yet. We started with using Docker directly because we were very familiar with it, and thought users might want to “preview” a dockerfile before asking devbox to build a container (we don’t have that yet, but can easily add it) That said, I do want to experiment with building the container directly through nix and seeing if there’s advantages to doing that. I just haven’t had the time yet.
Makes sense. I'll keep an eye out. Tilting at other windmills for now, myself. Congrats on the great start :)
Re: Show HN: Devbox – Easy, predictable shells and containers
#68Looks really good. A layer over Nix that makes it tolerable sounds like a godsend. I’ve had a TODO item for “somehow use Nix for our dev env” at Notion since 2019, but I keep kicking the can down the road because its better to tolerate a 500 line setup script than learn all the Nix stuff. Of course we could use Docker, but then on Mac our dev process would be 3x slower. Congrats to Daniel and the team! Excited to see…
I just set up a docker dev environment on Mac and I would not call it slow anymore. If you were referring to volume mounts, they are 10x faster now. Definitely fast enough for our work.
Re: Show HN: Devbox – Easy, predictable shells and containers
#69Earlier quoted context omitted.
It's likely you have not installed the pre-requisites: namely nix. Without nix, it can't find the package. That said, we'll improve the error message so that when nix is not installed it tells you you should install it.
As far as I can tell it is: 05:10:27 $ nix --version nix (Nix) 2.6.0 I installed it with `apt install nix-bin` on Ubuntu 22.04. EDIT: I installed Nix with the old-fashioned "pipe shit to bash" method and it seems to work now. When I say "work", I mean it in the sense of "doesn't fail", because it's been stuck at `devbox shell` for a good five minutes now with no indication. Not to be too negative, I think this is a g…
The package you want on Debian is called nix-systemd-setup or something like that, not nix-bin. (nix-bin just gives you the Nix binary, and I guess if you created /nix yourself you could use it for a single-user install.) The expectation is that you want a multiuser install, which requires a running daemon and the creation of some system users, and the nix setup package handles that. I think the package descriptions do outline this, and FTR you almost never want just a `-bin` package on Debian-based distros. The convention is used to allow minimal installation of just the binaries from packages when they're likely to be used by other parts of the system rather than end users.
The Nix package for Debian has some other deviations in the way it's plugged into the system and the initial setup. The default channel (source of packages) doesn't get set up for you, the PATH ordering is different, and NIX_PATH and the NIX_PROFILES_PATH (and maybe PATH?) aren't configured for `env_keep` with PAM's `sudo` configuration so interactions with `sudo` are different. Anyway failure to find any packages is probably due to the lack of enabled channels or the setup not being completed (needing that systemd-setup package).
(All of this stuff is up to the maintainers of the Debian package and Debian policy. It's fine, but it violates the assumptions of some third-party Nix tooling.)
Re: Show HN: Devbox – Easy, predictable shells and containers
#70Earlier quoted context omitted.
so an abstration on top of docker?
It uses the Docker CLI to build container images out of the Nix shells it creates, if you ask it to export one to a Docker image for you. Otherwise it just uses Nix locally, no virtualization. I wonder if it takes this approach because there's some issue with using Nixpkgs' dockerTools on macOS— those tools let you create Docker/OCI images without even having Docker installed.
docker is not virtualization either