Live data from Hacker News

Show HN: Flox 1.0 – Open-source dev env as code with Nix

github.com

101–110 of 201 posts

Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix

#102
post #73

The line about nix making it easier for newcomers in the readme and similar statements always trigger me. I am quite a competent person and I've never once thought "that was easy" when trying to use nix. I adore the concepts of nix, but the user experience is awful. Maybe that's what this tool solves? It takes a frustrating amount of effort and incessant config tweaking with little to no documentation and navigating…

Hard agree. I see the advantages but the initial learning curve is incredibly steep. Funny how this mimics my experience with Rust.

Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix

#103

There are several tools in this space now- nix is maturing and people are realizing how useful nix can be for dev envs. * [devenv](devenv.sh) - I am using it and loving it, but worried that the development is not moving forward * [devbox](https://www.jetpack.io/devbox) * [daytona](https://www.daytona.io/docs/usage/workspaces/) * [devshell](https://github.com/numtide/devshell) * [bob.build](bob.build) more focused on…

+1 to devenv. I used to use Nix natively, then switched to devbox and then devenv. devenv is the most intuitive to use. I just wish that I could just run a command using devenv (similar to nix run) instead of having to declare it in the devenv.nix first.

I use devenv with flakes. That allows me to use standard Nix commands including nix run.

Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix

#104
post #15

What’s the current relationship of the project with DE Shaw and how did you end up making a company on top of this?

Thanks for asking! I'm Michael Brantley, Flox CTO and formerly responsible for build and release engineering at the D. E. Shaw group. The high-level summary can be found in https://flox.dev/about but the back story is that I started diving into Nix in late 2017, and once I finally understood how Nix worked, how amazing the Nix community is and the incredible potential of the Nixpkgs collection I immediately realized I'd been "doing it wrong" all this time! It was then that we embarked on an effort to deploy Nix internally, but soon ran into many obstacles to enterprise adoption.

As I'm sure will be similar for many other teams, our Nix deployment started life as a series of bespoke applications and systems created to address such obstacles, but I suppose the difference in our case was that we had an internal venture studio called DESCOvery who recognized the impact that it could have on devs everywhere, and then worked closely with Ron, founding engineer Tom Bereknyei and me to launch the business. It's been an awesome journey - we hope you like it, and stay tuned for more to come!

Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix

#107
post #92

Earlier quoted context omitted.

As opposed to Docker, or Bazel? Conversely I have never had this problem with Nix. It tells you plainly how to clean up garbage. It's easy to interrogate to find out what's hanging around, and why. The reason it's not on by default is that, like any garbage collector, it can be disruptive -- there is no "one size fits all" policy. Ultimately if you have too many gc roots you have to make some decisions.

The problem (especially pre-flakes) with nix (and Docker too; haven't used Bazel) is that if you GC, you can't recreate your previous environment (which version of nixpkgs were you using when you built it/which day did you run apt-get update in your Dockerfile). It appears that Flox uses flakes and versions the flake.lock file, so it should be possible to readily reproduce anything that hasn't completely disappeared…

True, but with Flakes, as long as you didn’t upddate your lock file, you should always be able to rollback to your previous environment.

On NixOS, you can then configure background GC to clean up the Nix store periodically: https://search.nixos.org/options?channel=23.11&from=0&size=5...

Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix

#108

There are several tools in this space now- nix is maturing and people are realizing how useful nix can be for dev envs. * [devenv](devenv.sh) - I am using it and loving it, but worried that the development is not moving forward * [devbox](https://www.jetpack.io/devbox) * [daytona](https://www.daytona.io/docs/usage/workspaces/) * [devshell](https://github.com/numtide/devshell) * [bob.build](bob.build) more focused on…

Nix allows you to have a single lock file for all your dependencies. This is very useful for development environments. When you share a lock file via Git, then you know your colleagues will be running the same versions.
Post reply on HN