Hacker News Reader

Comment by ivanjermakov | Hacker News Reader

What is the benefit of using Flox over plain nix-shell or nix develop?

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

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.

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.

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

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.

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.

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"

Put another way, I would think that individual engineers would be better off learning the underlying tech and the tools provided that go with them. I think it's very possible that Flox (or devenv or...) reaches EOL, or ceases to track nixpkgs appropriately, or any of the other ways that software rots. Where nix develop is going to last as long as Nix Flakes do, and there's incentive to provide a migration path to whatever's next.

Even more important: every abstraction is going to leak. Maybe the Flox CLI "looks" cleaner or whatever, but in the end you'll still need to learn Nix to use it effectively. Why learn twice as much stuff as you need?

I use Nix at work, to distribute tools to (among other places) developers outside my team. I'm also the person within my team who knows Nix best.

We're currently using devenv.sh to present a prettier interface to those users, who are developers. I don't expect those devs to learn much about Nix, but I do expect to some extent to be responsible for educating and supporting them as issues inevitably come up.

I've not really tried Flox (now that I can do so without any signups and the CLI tool is open-source, I'm more seriously tempted to dig in than before!). But for me, the proposition isn't really learning 2 things vs. 1 or even asking other people to do so. The question is which interface is going to be easier for me to support— my expectation is that if/when things go awry, I'll end up relying on the same Nix knowledge either way. So I don't really see Flox changing what the developers I support are expected to master, but if Flox is something that developers I support find convenient and pleasant to use, I can imagine it reducing UX and documentation work I have to do with the Nix-based tooling I'm gluing together. It may also save me infrastructure burdens, in terms of setting up shared binary caches or helping users share environment configs and Nix code.

I'd really love to support a developer so obsessive and curious that they felt the need to learn and master Nix because they were using Flox as a dependency of my project. I'd like to think that as someone who knows my way around the Nix ecosystem, I could make exploring how Nix works and how Flox adds to it fun for them. But I can also imagine being that developer and feeling annoyed at the prospect of 'having' to learn two tools. I hear that.

Does a python developer NEED to know how C works to write automation scripts that work reasonably well? This logic is silly.

They don't, but I have respect and sympathy for developers who prefer to dig deeper with learning their tools, and how that might make them tend to prefer stacks with fewer layers sometimes. I think it's a valid concern, especially for hobbyist and experimental/autodidactic use cases. In a corporate environment or within a team, people typically specialize and defer to each other in various areas, so maybe it matters less there.

Or https://devenv.sh

or https://www.jetpack.io/devbox/ :ˆ)

Ah! The modern hell of choice. Can’t these peeps just work together and make one great thing instead of fragmenting over and over? I think I know the answers but have to ask anyway, hope to learn.

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 discussing direnv, not devenv -- which appears to be a direct alternative to Flox

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).

> this doesn't do services, but there was a flake util just announced that adds support for that

You must be referring to services-flake:

https://community.flake.parts/services-flake

yes, thanks!

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...

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 directly. It's what underpins home-manager as an example.

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.)?

> Is it that the latter is for actually building/running the debug build locally

Yes, I think. `nix-develop` sets up the environment variables and functions required by the build, both on the Nix side and on the side of the application you're trying to build. So you get all the variables that will be in play in the Nix build sandbox, from the bash functions for each phase of the build and Nix-specific env vars to env vars for things like your CMAKE flags or your PYTHONPATH. `nix develop` lets you interactively explore the build exactly the way Nix will do it, so you can test each piece and maybe even try some manual build steps that aren't yet in place for a build that's not entirely working.

`nix shell` is a simpler 'hey, equip my $PATH with these programs, thanks'

I am no expert, but yes, it's flakes for my projects. It keeps the build time tooling separate (eg Go compiler, node version,etc) from the main system (so I could for example have different versions for different projects). It also makes it easier for others that might (one day) contribute to my projects to start developing (assuming they're using nix) with the same tooling and versions that I am using.

aiui, nix shell was the non-flake way of doing things and nix develop is for flakes (this is probably a gross over simplification!)

nix DASH shell (`nix-shell`) is a pre-flakes command. nix SPACE shell (`nix shell`) is a flakes-based command.

Flakification split two common use cases of nix-shell into two separate commands, `nix shell` and `nix develop`.

I guess it somewhat follows the Nix tradition of having several pieces of software doing the same exact thing and confusing the users about which one to pick.

That’s equivalent to demanding the Python community to abolish PyPI in favor of making the “one great” standard library. Nix is a language after all. It’s meant to have tools that build on it.

IMO it's a bit more like asking the python community to standardize all the tools listed in this stackoverflow question, which they only sort of succeeded in.

"What is the difference between venv, pyvenv, pyenv, virtualenv, virtualenvwrapper, pipenv, etc?"

https://stackoverflow.com/questions/41573587/what-is-the-dif...

Nix comes with confusion built in though, in the official getting started guide flakes are described as controversial, their history explained, criticisms described, only to ultimately say you have to decide for yourself.

Imagine if the Arch or Ubuntu installer halted, told you neutrally / BBC style criticism-focussed even about systemd, and then asked you how to proceed: systemd or sysvinit?

I both love this and totally understand why it can be overwhelming for new users. (I had no idea this was a thing because I've been using (and loving) the flakes-centric DetSys installer for so long now.) It reminds me of how in legal contexts, dissenting views are also part of the record (and can be cited in future cases sometimes), or how in the context of traditional commentaries on certain religions (Islam and Judaism come to mind, but I'm sure there are others), the tradition is not just to record and teach a 'winning' side, but to record and teach the entire debate.

Can it be overwhelming? Yes. Is it the kind of thing engineers are looking for? Often, no. But it is a deeply respectful and thoughtful way to treat people and topics imo.

I guess, but the huge ambiguity of it to me, that I think should be resolved, is is it the future of the project? However controversial it was and respectful it is to give me the choice, my choice is that I want to do what's going to be best supported by the first party, what does upstream expect me to do, especially as a newcomer just trying it out.

(Again, rather. When I first tried it out flakes didn't exist. And actually that makes it even more confusing because the nix profile, nix env stuff I dimly recall is apparently deep plumbing nobody's really expected to use directly any more.)

Maybe the answer is no flakes, because it's disabled by default after all. But then it really does seem like everybody uses flakes now.

Your analogy would've made sense if Nix had a few dozen implementations to choose from, all being similar in scope and none being definitively better. These are tools that build upon Nix. The whole point of a language is to have tools that build upon it. It's nothing line the Python -env situation where the sole purpose is to mitigate a design flaw in packaging.

Well, I wonder about all language communities why they don’t coordinate efforts indeed. I see monthly arrivals of new ‘js runtimes’ and package managers as well. And that eco system is a lot larger than nix. If these talented people would band together, wouldn’t we get a better endresult as a whole? If it’s commercial products then that doesn’t work, but this is all nice open source under good licenses, so outside ego, what’s the benefit of 50000 things that do the same thing except 499XX*n hours of life wasted?

Reply on news.ycombinator.com