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

91–100 of 201 posts

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

#91

Post by rapnie »

jahsome wrote: 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…

Agreed on the experience, hard to onboard. I looked at devenv.sh as easier way to get going. Implemented all with Nix, less lock-in. Just found std [0] and that looks quite promising too.

[0] https://std.divnix.com/

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

#92

Post by aidenn0 »

xyzzy_plugh wrote: post #60
solatic wrote: post #35

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 wh…

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 from the internet.

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

#93

Post by SkyMarshal »

jaxr wrote: post #78
jahsome wrote: 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…

Exact same experience here. Been fiddling with nixos for quite a while, but never got comfortable with .nix or flakes. The base concepts keep escaping my mind, I have to revisit every time I have to configure something new and I just got tired. Issues are difficult to debug and you have to go through very specific commands and a hellish filesystem to understand what's going wrong. I love the concept, but I feel like…

> and a hellish filesystem

What do you mean by this part? The actual filesystem like Ext4/ZFS/etc? Or the removal of the unix Filesystem Heirarchy and replacement with a simulated/softlinked version in Nix/OS?

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

#94

Post by tomberek »

flurie wrote: post #63

Hello Ron, congratulations to everyone on the team! It looks like you've pared back some of the more expert configurability in order to clean up the UX. I really like the environment focus and composability, which is a real pain point in the Nix world. Do you have a plan to add back any of that configurability over time? I realize I am probably not your target audience, at least as a free user, and perhaps your enter…

Yes. We have designs to allow for more powerful configuration for experts. A good example of this is let people use alternative manifest representations; JSON, Nix, etc.

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

#95

Post by dataangel »

Rucadi wrote: post #39
cal85 wrote: post #16

Earlier quoted context omitted.

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 b…

I tried NixOS because I needed to recreate an environment with a specific GCC version. It was absolute hell, you are likely looking back on your experience with rose colored glasses now that you know how things work. Even really really really basic shit was insane, here's an example: the whole system is built on hashes, and there is no consistent format for them! I was getting an error with hash A even though I explicitly requested hash B, and I couldn't figure out why. Turns out nix can't decide whether to use base32 or base64....

I also tried passing arguments to specify the GCC version in like 10 different ways, *that all failed silently*. Staying far far far away from Nix even though on paper I should love it.

Edit: oh yeah and `nix shell` and `nix-shell` both exist and don't do the same thing

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

#96

Post by tomberek »

troymc wrote: post #57

I wonder if something like this could be used instead of conda or pixi to manage Python packages, the used-version of Python, the Python virtualenv, etc.

The python ecosystem will require specific support, so at the moment we recommend using `flox` to get all of the other things that might not be managed by an existing Python package manager, and/or to install that package manager itself.

Being a general solution, `flox` cannot directly provide the same level of integration as a python-specific tool, but we CAN make it easier to use those other tools, and bring in others.

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

#98

Post by notresidenter »

tomberek wrote: post #51
notresidenter wrote: post #21

Earlier quoted context omitted.

You know you can just write `nix develop -c zsh` or `nix develop -c fish` or whatever, right?

Yes, I'm also a Nix maintainer. `nix develop` does many other things, originally based on re-creating the build environment of a derivation. This means that it is not ideal for the case of development environments that must support more than just building.

Interesting, thanks.

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

#99

Post by OJFord »

zamalek wrote: post #85
OJFord wrote: post #31

Earlier quoted context omitted.

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…

Nix shell is for devshells declared as a top-level in your flake. 99.99% of the time this is identical to the primary package, but sometimes having additional things around is helpful. E.g. I use justfiles for local dev (meaning I have to pull Just in as a dep), but that isn't something used for a real package build. Nix profile is for activating profiles, which even a seasoned nix user would have little use for dire…

I suppose what I'm missing then is why you ever need to switch from nix shell to (your just etc. -less) nix develop environment?

Is it that the latter is for actually building/running the debug build locally, like a `docker compose up --build` for example? i.e. it's the environment the thing you're working on runs in, but you working on it run in nix shell (with just, git, docker compose in that example, your editor, etc.)?

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

#100

Post by mrbonner »

gregwebs wrote: post #64

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.
Post reply on HN