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

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

github.com

Post reply on HN
Print view View original

31–40 of 201 posts

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

#31

Post by OJFord »

vhodges wrote: post #19
zamalek wrote: post #14

Earlier quoted context omitted.

Devenv and devbox are completely different. Devenv will merely automatically install envars into your env from a plugin (one of which handles nix). If you aren't using devenv you are missing out, irrespective of whether you use nix. Devbox is a direct alternative to Flox. Edit: all incorrect, I got confused. There are indeed to many of these Nix wrappers.

I think you're referring to direnv as opposed to devenv.sh which does compete in the same space. Numentide was working on one too. I am using devenv.sh at work, at home I just nix develop (but this doesn't do services, but there was a flake util just announced that adds support for that I need to check out).

Why `nix develop`, not `nix shell` or `nix profile`? Because you're also packaging the final result with nix anyway or something?

> nix develop starts a bash shell that provides an interactive build environment nearly identical to what Nix would use to build installable. Inside this shell, environment variables and shell functions are set up so that you can interactively and incrementally build your package.

I'm not saying it's bad or wrong - it's a long time since I've used nix and it's changed/progressed a lot, and I'm considering it again so just keen to understand.

edit: also just found shell.nix & nix-direnv integration - https://nix.dev/tutorials/first-steps/declarative-shell#decl...

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

#32

Post by OJFord »

focom wrote: post #29

Sorry to be this guy, but why is Nix better than a docker dev container?

On non-Linux it should be faster/less overhead; on all platforms I suppose it's just arguably easier/quicker to make changes & 'rebuild', and then the result is that that just is your environment, it's not a container inside it that you have to exec into or run commands through or make your IDE use or whatever.

But mostly it's just two different approaches and people will be happy to argue about why there's is better, or that they don't use either (just the system environment (on a non-NixOS system..) as it were).

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

#33

Post by tomberek »

focom wrote: post #29

Sorry to be this guy, but why is Nix better than a docker dev container?

It's not necessarily that one is better than another; it can be complementary. I tend to think that Nix makes many of the reasons to use a container superfluous, but there still remain other reasons to use containers.

For example, a talk about using both Docker and Nix (yep, that's me ;) ): https://www.youtube.com/watch?v=l17oRkhgqHE

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

#34

Post by stephenr »

So, I read about a similar-ish tool to this recently, `devenv` - it sounds like both tools are based around Nix.

The other article (talking about `devenv`) was discussing a migration away from running Vagrant.

I had questions then that I still have now with this tool: assuming this, like `devenv` doesn't directly run a VM, how exactly do you solve actual platform differences - e.g. it's quite common to have developers using macOS or Windows, and production servers running a Linux distro.

Sure, some things work the same or close-enough to the same, but even with scripting languages (no aot compiling) that have pretty good cross platform support, there are differences either in features, extensions, or in system level dependencies (i.e. a database server, cache server, etc).

Vagrant is one solution to this problem, as is "Docker in a VM", albeit a little less flexible IMO - essentially you run a "close to production" environment inside a VM, with zero worries about what the host environment is, because the software is still running in basically the same environment as prod. The rise of Arm workstations has made this interesting, but Debian 12 on Amd64 is still a heck of a lot closer to Debian 12 on Arm64 than it is to macOS or Windows on anything.

So what is the Nix solution to this problem?

It sounds like the best you'd hope for would be to run Nix inside a VM, potentially managed by something like Vagrant (thus giving you a reproducible VM running a reproducible environment), but a number of comments I've seen about using `devenv` or nix made a point of "no VM required".. so that just makes me wonder, am I missing some vital piece of information about Nix, or are these people just running much simpler dev environments than I'm used to?

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

#35

Post by solatic »

One critical issue with "power of Nix without the learning curve" kind of products is that you still have Nix behind the scenes, including the /nix/store, which is intentionally not cleaned up by Nix automatically. So when users try out something that hides Nix from them, their drives inevitably fill up, which is super user-friendly because they have no idea how to reduce the amount of storage used. It's different when users understand that they're installing Nix, and go through the learning curve, because that learning curve helps them to build the mental model of what /nix/store is and how to maintain it.

What's your strategy for dealing with the underlying complexities?

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

#38

Post by ParetoOptimal »

OJFord wrote: post #32
focom wrote: post #29

Sorry to be this guy, but why is Nix better than a docker dev container?

On non-Linux it should be faster/less overhead; on all platforms I suppose it's just arguably easier/quicker to make changes & 'rebuild', and then the result is that that just is your environment, it's not a container inside it that you have to exec into or run commands through or make your IDE use or whatever. But mostly it's just two different approaches and people will be happy to argue about why there's is better…

I mostly agree, but one big thing missing is Nix is reproducible by default while docker is only repeatable.

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

#39

Post by Rucadi »

cal85 wrote: post #16
Rucadi wrote: post #9

I really don't understand why should I use this over plain nix, can you elaborate?

I just want clean, repeatable environments for different projects. I’ve tried getting into Nix a few times but I always get overwhelmed by all the different things it is/does. This looks 100x simpler to me.

Hmm...

I understand that if you don't know anything about the language or what is a flake, it may be a little bit difficult.

But really, adding a new package to your environment once you have a flake setup, which a minimal one is trivial, is just adding the name of the package.

Here you have a flake.nix example from leptos. https://github.com/leptos-rs/leptos/blob/main/flake.nix

You want a new dependency? Add it to buildInputs. (this one doesn't have packages setup, but anything in the attribute set packages will be available in path)

You want to search a package: https://search.nixos.org/packages (or use the cli)

you want to test a package before adding it? nix-shell -p or nix shell for example.

Heck, even if you want it more easy, you could write a tool in less than 100 lines that adds packages names to .json/.yaml/.toml, which allows you to parse it using the nix language and a simple cli written with bash functions to add/remove packages if you wanted.

That's why it is hard for me to understand this project as a product, it seems like a wrapper to the most basic things :\

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

#40

Post by ParetoOptimal »

dymk wrote: post #28
ceving wrote: post #13

I do not understand the usecase. If I need a particular environment I will install it in LXC.

That doesn’t solve “works on my box” or reproducible builds Developer environments should be cattle, not pets once you’re working with more than a few engineers

The default supported developer environment should be cattle not pets, but developers should be free to have pets.
Post reply on HN