Comment by mkenigs | Hacker News Reader

Comment by mkenigs | Hacker News Reader

Parent Full thread

Flox employee here! To start off by addressing how this relates to nix tools:

- Our goal is to be more user friendly. You don't have to learn the Nix expression language or understand nix internals to be successful.

- We've been able to add some opinionation and polish. Some of that is subjective, but some examples are:

  - We have a hybrid imperative/declarative interface. You can `flox install && flox list`, and those changes are reflected in TOML. Whereas with `nix develop` you have to edit a Nix expression

  - `nix develop` drops you into a bash shell, whereas `flox activate` can drop you into a bash or zsh shell (and we plan to add support for fish)

- We support using git to manage environments just like nix tools do, but we've also added the option to share flox environments in ways you can't with any of those tools (flox push/flox pull/flox activate -r) and the ability to view environments in ways we feel can be more user friendly. If you create an account, you can see packages I have in my environment at https://hub.flox.dev/mkenigs/default, or if you have the CLI, you could inspect my environment with `flox list -r mkenigs/default` before using it with `flox activate -r mkenigs/default`. I think that's much more digestible than linking a flake.nix to someone who doesn't know the Nix expression language

So what you are offering here is essentially a small UX improvement over sharing a flake with a devshell in a Git repo?

I'm the first to admit that nix is way too cumbersome to use, but this alone doesn't seem like enough value add.

If you think this is a "small" improvement on Nix's UX you clearly have never used Nix.

Or they've used it so much that they no longer have to think about stepping around Nix's UX quirks. Once the habit is automatic a lot of the UX difficulties that can be striking at first become invisible, or at least forgettable.

It sounds like: "Dropbox is a small UX improvement over rsync"

The value needed by Nix is not more/better tech but an on-ramp for people who want to use Nix without learning all about all the various ways to do thing. Just having a single, opinionated onboarding experience will add a ton of value to the project.

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.

Isn't there nix shell for that, and nix-direnv to activate automatically?

In some environments, not-building stuff you might want to do could include launching/supervising long-lived processes (services), connecting networked filesystems and mounting them somewhere appropriate, firing up VMs, etc. Some of this you can definitely do with direnv but if you want reproducibility with those aspects of your environment, building it on top of Nix seems like a more natural fit to me.

There are other tools that compete in this space right now (devenv.sh, flake.parts, devbox), and for simple use cases a basic direnv integration might be just fine. But the role Flox is aiming for here seems pretty clear imo.

Interesting, thanks.

Does this save environment variables and aliases defined in the Nix devshell?

Reply on news.ycombinator.com