HN Explorer

Show HN: Flox 1.0 – Open-source dev env as code with Nix (github.com)

382 points by ronef ↗ HN
Hey HN,

I'm Ron Efroni, CEO at Flox, and today we are releasing version 1.0 of our open source CLI, helping folks manage development environments everywhere.My own experience with development environments began with air-gapped systems, having to actually burn software to a CD to iterate over a very slow and expensive development cycle, sometimes reaching the server rack and realizing I have the wrong disk.... Fast forward to today and there are countless alternatives available backed by incredible compute resources, yet we somehow still find ourselves paying the price of long development cycles. That's why I've been working for over a decade to simplify the development stack so we can spend more time on making 1's and 0's do magical things, and why my co-founder Michael and I started Flox to bring you the solution based on Nix. Today is just the first step on that journey. We hope you'll take a peek at our new release, and very much look forward to continuing the journey with you from here together!

Introducing Flox 1.0

Flox is a platform that lets developers and operators focus on building fast with reproducible environments that span the enterprise SDLC. Using a declarative framework based on Nix, a package management and configuration tool, Flox allows developers to create environments that contain everything they need to build software.

Why Flox?

Flox behaves a lot like your favorite and familiar package manager, but it allows you to create as many environments as you want on your machine. Each one can contain a different combination of packages.

Environments are portable by default. If you install a package inside one that isn't cross-platform, it's easy to carve out exceptions. It's also easy to write hooks and populate your environment with variables - we designed it to be hackable.

Flox environments run in user-space, like, where you are. When you type `ls` after activating a Flox environment you will see the same stuff because you're in the same place - even with all those new packages available. No mounting volumes, no proxying ports. No breaking into the toolset you just conjured.

Getting Started: No sign-ups, just one install away. Dive into our GitHub repository (https://github.com/flox/flox) and start exploring

I’m around all day to answer questions, talk Nix, or just reminisce about simpler times ;).

Lots of open source love, Ron

200 comments

[ 3.6 ms ] story [ 259 ms ] thread
ivanjermakov
What is the benefit of using Flox over plain nix-shell or nix develop?
mrd3v0
Or https://devenv.sh
slekker
or https://www.jetpack.io/devbox/ :ˆ)
anonzzzies
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.
zamalek
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.

smw
I think you're discussing direnv, not devenv -- which appears to be a direct alternative to Flox
vhodges
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).

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

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

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

pxc
> 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'

vhodges
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!)

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

mrd3v0
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.
soraminazuki
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.
EE84M3i
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...

OJFord
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?

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

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

soraminazuki
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.
anonzzzies
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?
mkenigs
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
notresidenter
You know you can just write `nix develop -c zsh` or `nix develop -c fish` or whatever, right?
tomberek
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.
OJFord
Isn't there nix shell for that, and nix-direnv to activate automatically?
pxc
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.

tripdout
Does this save environment variables and aliases defined in the Nix devshell?
the_duke
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.

eikenberry
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.
joshcsimmons
If you think this is a "small" improvement on Nix's UX you clearly have never used Nix.
pxc
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.
d0mine
It sounds like: "Dropbox is a small UX improvement over rsync"
shubber
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?

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

joshcsimmons
Does a python developer NEED to know how C works to write automation scripts that work reasonably well? This logic is silly.
pxc
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.
e3bc54b2
If I understand correctly, the linked repo is for flox CLI client. While it is welcome, is there a plan to open source the service components? I'd like to deploy flox on my own and have portable environments. Otherwise this I'd just another SaaS with lock-in and "lots of open source love".
ronef
we will always allow the CLI to stand alone for a local developer or CI runner. the service side of Flox is for those who want a faster performance, easy sharing, or eventually enterprise control. so while the CLI can use the closed service it's purely optional (and will always be optional)
Rucadi
I really don't understand why should I use this over plain nix, can you elaborate?
cal85
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.
Rucadi
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 :\",

malkosta
I once needed to install a specific version of a package on my nix environment. It took me 2 hours to find how...

After a few months, I needed to do that again, but now the project supported devenv.sh. It took me 5 min.

That experience also repeated for other kinds of tasks, for example: start postgres (or redis or elasticsearch or cassandra...), install packages only if the host system is `darwin`, install old versions of packages that aren't on the registry anymore, etc...

Rucadi
How does devenv help with using an specific version of a package in an easier way than nix (with flakes)? Does it have any kind of simpler syntax for overlays? Or you are referring to pinning a nixpkgs version?

I'm not really against tools that make it easier to use nix, I think devenv is a nice tool and I like that it doesn't hide nix, the same way I love home-manager and use it all the time.

malkosta
> I like that it doesn't hide nix

Yep. That's my main argument for it against devbox.

> Does it have any kind of simpler syntax for overlays?

Yes, it does. But what helps isn't that, but the concise docs with just the information I need to know to get up and running quickly: https://devenv.sh/getting-started/

I've read multiple docs/books on Nix, but I always find myself lost when I need to accomplish anything simple. With devenv, I can spot most of my answers from the docs menu. They are all a single click distant from me.

dataangel
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

waldrews
Respectfully, I'd like to nominate "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." as the next "why would you need dropbox" comment ( https://news.ycombinator.com/item?id=9224 ).
tomberek
I understand that Nix solves many problems and indeed bet on its ability to do so. It is why I've put so much effort into Nix itself.

However, Nix poses a relatively steep learning curve being built up from first principles making it very general. Flox aims at simplifying this by narrowing the problem field and providing specialized abstractions and interfaces for those who want to benefit from nix' capabilities without needing to becoming a nix expert at day 0.

(flox employee)

ParetoOptimal
Selling coworkers on flox or devenv is way easier than Nix.
peterldowns
Hi Ron, congratulations on the release. My question is: how will you make money? I see you are the CEO, there is a company, and you have employees. Crunchbase links to news articles that make it seem like you've raised $24MM. Maybe I'm just missing it, but I can't see any pricing information on your landing page or in your docs. After I log in to FloxHub with my Github profile, I don't see any billing options. What is your plan?
ronef
Appreciate the call out. Regarding pricing, bringing forward what you saw today for free and open source, was a major part of why I started Flox, with much more to come into it. What we released today will be free forever (both the open source client and the FloxHub services for sharing environments). We plan on expanding the offering to include a more robust private software catalogs that layers on top of the OOTB Flox Catalog that ships with Flox. If you are interested in publishing your output or need revised versions of open source packages in Flox then it'll be very easy to have your own catalog to compliment the always-free Flox Catalog that Flox ships with today. Beyond that, we are focused on a number of services that help bring Nix's build to the enterprise. Over time we intend to sell a solution to enterprises - through subscriptions and services - so they can more effectively manage expansive and fragmented software supply chains. As part of developing custom tooling for enterprises, we think it's reasonable for them to participate in funding for that work.
[deleted]
(comment deleted)
peterldowns
Thank you for the answer. Best of luck to you and your investors!
IshKebab
Good luck! My experience of Nix, and similar "robust engineering" solutions like Bazel is that there are a handful of people that get it, and see the benefits. But there are hoards more that think you should just write hacky shell scripts and bugs don't really matter anyway.
elbear
There are also the people who get it and see the benefits, but don't want to put up with the work required to have your system or environment managed with Nix. If this tool simplifies things, it could get traction.
yencabulator
> Crunchbase links to news articles that make it seem like you've raised $24MM.

Oh wow. I really don't see a way to a $2.4B exit here. Good luck!

ceving
I do not understand the usecase. If I need a particular environment I will install it in LXC.
dymk
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

ParetoOptimal
The default supported developer environment should be cattle not pets, but developers should be free to have pets.
xrisk
What’s the current relationship of the project with DE Shaw and how did you end up making a company on top of this?
michaelbrantley
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!

[deleted]
(comment deleted)
sandGorgon
https://news.ycombinator.com/item?id=39616709

a few days back daytona was also released. any thoughts on how it differs ?

ivan_burazin
Happy to take this one, as I am one of the cofounder of Daytona.

Daytona solves all the automation and provisioning of the dev environment, actually wrote an article here laying out exactly what we do: https://www.daytona.io/dotfiles/diy-guide-to-transform-any-m...

Daytona currently supports only the dev container (https://containers.dev/) "dev env infrastructure as code" standard, but are looking to support others such as devfile, nix and flox.

Hope this helps

sandGorgon
ahh interesting - so there's a split on the dev format. why did you choose dev containers vs nix ? genuine question - asking because replit makes a big deal of nix, so it seemed to me as a very popular choice.
nkko
Dev containers provide a robust standard that is seamlessly integrated into VS Code, which makes workflow smooth end-to-end. Thanks to the Daytona plugin architecture and Apache license, it is relatively easy to bring in more standards. Cause, you know: https://xkcd.com/927/
ivan_burazin
You only have so many things you can do at once.

From our perspective dev container seemed to be what our target audience was already using; as its supported by VS code natively and also as almost all OSS projects are hosted on Github, and their product Codespaces support it as well - it seemed like the logical first standard.

But as mentioned devfile, nix and flox are on the roadmap.

Cu3PO42
Congrats on the launch!

I love Nix. I really do. I also recognize the onboarding experience is bad at best and terrible at worst.

As such I welcome any effort to make it more approachable. I believe the imperative CLI is a great step in that direction. It's much closer to what many people expect and will feel comfortable with. Simplifying the "using an environment from somewhere else" story is also one I strongly relate to.

One thing I'm not seeing that I think would be important is IDE integration. Starting your IDE from the command line inside the environment is not intuitive to many of my colleagues and is something I've diagnodes as the root cause of an issue more than once.

What's your story for dropping down into 'real Nix' if required? I'm a bit afraid that this might drop you off at a cliff for somewhat more complicated environments, for example to set up a cross-compilation Rust toolchain.

To stick with the example of Rust development, I have the following shellHook in one of my Flakes:

    export LIBCLANG_PATH="${pkgs.llvmPackages.libclang.lib}/lib"
    export RUST_SRC_PATH="${pkgs.rust.packages.stable.rustPlatform.rustLibSrc}"
    export BINDGEN_EXTRA_CLANG_ARGS="$(< ${stdenv.cc}/nix-support/libc-crt1-cflags) \
        $(< ${stdenv.cc}/nix-support/libc-cflags) \
        $(< ${stdenv.cc}/nix-support/cc-cflags) \
        $(< ${stdenv.cc}/nix-support/libcxx-cxxflags) \
        ${lib.optionalString stdenv.cc.isClang "-idirafter ${stdenv.cc.cc.lib}/lib/clang/${lib.getVersion stdenv.cc.cc}/include"} \
        ${lib.optionalString stdenv.cc.isGNU "-isystem ${lib.getDev stdenv.cc.cc}/include/c++/${lib.getVersion stdenv.cc.cc} -isystem ${stdenv.cc.cc}/include/c++/${lib.getVersion stdenv.cc.cc}/${stdenv.hostPlatform.config} -isystem ${stdenv.cc.cc}/lib/gcc/${stdenv.hostPlatform.config}/${lib.getVersion stdenv.cc.cc}/include"} \
        $NIX_CFLAGS_COMPILE"
It was necessary to get Rust-Analyzer to play nice. How would I ever set something like this up in Flox? Is this kind of setup something you want to abstract away? If not, how would this ever be discoverable to a user that isn't familiar with Nix?

Please don't mistake these questions as me saying this can never work. I really want it to work, I just don't know how yet.

tomberek
> What's your story for dropping down into 'real Nix' if required?

We already have talked about this and plan to allow using Nix itself in those cases where someone needs the additional power. The current thought is to have allow a either a reference to a flake for specific fields or to have an Nix-style entrypoint.

This is not yet exposed or documented. Stay tuned.

aside: absolutely agree that there is a fine line between hiding complexity and exposing power

focom
Sorry to be this guy, but why is Nix better than a docker dev container?
OJFord
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).

ParetoOptimal
I mostly agree, but one big thing missing is Nix is reproducible by default while docker is only repeatable.
OJFord
Yeah, I was just trying to avoid anything to which you could say 'well I can do that with docker [and appropriate care & attention]'.
tomberek
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

Rucadi
I have to use both at the same time.

I have a Docker with an old version of centos which for some reason is the one provided to us.

I then create an "overlay" over it using nix, so I can actually use software with newer glibc etc... easily.

Regardless of that, nix is way better than docker, in the sense that docker doesn't ensure reproducibility, you can build a Dockerfile in two different days, and get different versions of packages installed, this is simply not possible with nix, you have complete control over your tools.

And if you decide to port your application to a "nix package", you have complete control over all the dependencies of you application, a reproducible way to build it, and an easy way to deploy it.

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?

tomberek
Nix runs alongside other distributions in various OSs, including OSX. (Windows is being looked at, do not hold your breath.)

The cross-platform capability of `flox` comes from our usage of Nixpkgs, which includes allowance for some of the differences between platforms and makes them less of an issue.

If some piece of software has a specific difference when run on different platforms and you rely upon that difference, then your need to use that platform in some way: native, VM, translator, etc. Nix does make it easier to manage, build, distribute, multiple kinds of software.

Flox environments leverage this same foundation to expose the same environment on multiple systems and we plan to work on this more. What in particular would you be looking for?

Rucadi
Using Nix as a package manager works best with a repository called "Nixpkgs".

Nixpkgs focuses on reproducible builds, that means that for the same inputs, you always are going to get the same binary output.

All of Nixpkgs are built using nixpkgs, and they don't depend on any library outside nixpkgs, including glibc and compilers.

That means that you can "lock" your packages into a version, and you ensure that it will run the exact same version and configuration in all machines that you install it, no matter the underlying OS or how old/new it is, glibc problems etc...

This is the power of Nix.

All of this can be done via a simple

Flake.nix -> define the system Flake.lock -> automatically generated, defines the exact version of nixpkgs among others.

(Can also be done via channels but flakes are better imo)

Foxboron
> Nixpkgs focuses on reproducible builds, that means that for the same inputs, you always are going to get the same binary output.

This is a common misconception, nixpkgs only really supports "repeatable builds" and "reproducible build environments".

The Reproducible Builds aspect of nixpkgs is still very much a work in progress as it is with all the other linux distributions and hardly a focus.

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

The kind of default/minimum reproducibility for most Nix-based deployments is basically a stronger version of this. It's like 'Debian 12 on AMD64 with all the exact versions and non-arch-specific build flags of all packages exactly pinned is very similar to Debian 12 on ARM64 with all package versions and non-arch-specific build flags pinned to the exact same thing'.

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

This is worth digging into.

> there are differences either in features, extensions

Nix will guarantee for you that you always get the exact same features and extensions unless it's truly the case that a feature is just not available on some platforms. So it takes care of differences that come from different operating systems and distros using different ./configure flags and so on.

> or in system level dependencies (i.e. a database server, cache server, etc)

Flox and competitors like it all support local process supervision/service management as well as just adding packages to an environment, so you pin down the versions and configuration options of your DB server and cache server in the environment specification as well.

> Sure, some things work the same or close-enough to the same

For things that are genuinely different (e.g., Nix itself has different sandboxing features and support on Linux because those operating systems' respective kernels also differ in their capabilities), you are still going to want to virtualize. If your production environment is NixOS, there are some pretty nice tools available for this. Otherwise you might want to do your final testing via something like Vagrant or Tart or some custom Nix-based tooling.

But if Docker-in-a-VM is good enough reproducibility for your stack, Nix will probably be a little bit better.

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?

anon291
Just set nix garbage collect to run every thirty minutes.
pasc1878
The point being asked was how do you do the gc using flex, as the aim is to not have to go inti nix
tomberek
Supporting rollback and history means disks can fill up. With Nix, this is usually due to a bunch of GC roots pointing to profiles and packages that then cannot be cleaned up. Our environments are not just symlinks, but have a declarative format (under the hood, flakes) so one can remove them, but also reproduce them as needed. So GC'ing them is less destructive than with using `nix-env`/`nix profile`. This allows us to be more aggressive in cleaning up old generations.

So the strategy is to ensure there is always a declarative+reproducible way to recover the things you clean up, then we can apply various heuristics to avoid disks from filling up; free space, age, least-recently-used, least-frequently-used - are all being considered.

colordrops
Nix supports garbage collection.

Also there are literally thousands of insanely complex things happening behind the scenes every time you use your computer. Not sure why Nix is considered special when abstracting over it.

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

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

OJFord
Can't you just pin pkgs to particular commit, so everything will have the version it did as of that commit?
aidenn0
Right, but traditional nix doesn't make that easy (which is why niv and flakes exist).
OJFord
I suppose you're just saying it's easier than this with flakes, but this isn't a flake is it? (Honestly so confused about it all, looking at trying out nix again after toying with it briefly years ago.)

https://nix.dev/guides/recipes/sharing-dependencies#complete...

aidenn0
That is not with flakes, nor does it pin nixpkgs.

It tracks nixpkgs-23.11

Now at the bottom it links to an example of pinning without using flakes, but the page you linked directly does not pin nixpkgs.

Flakes pin by default, and defaults matter. Using flakes, anything that isn't explicitly listed with a hash to ensure it's unchanged must be explicitly listed as an input, and a lock file for the inputs is automatically generated.

Gimpei
Would this work as a simpler alternative to Nix home manager?
tomberek
Yes. For limited situations it provides a simpler interface. Flox won't provide exactly the same feature set, but there are many situations where home-manager is too much.

You can consider the current `flox` environment to be similar to a declarative profile, conceptually positioned between home-manager and devShells.

troymc
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.
Cu3PO42
It can, but I wouldn't recommend it unless you have native dependencies that are just a pain to install. You'll loose Windows compatibility, may have to package some Python packages yourself, have a learning curve for everyone in the Python ecosystem and gain... what exactly?
amarshall
I don’t use Flox, but do use Nix + poetry2nix for a few Python projects at work. It is a bit of a pain in the ass sometimes, but because it’s Nix, it’s never a pain till something is deliberately changed. The result is that our dev environments are way more reliable than before and project onboarding just works every time. We also use Nix to build for CI and production in these projects.
tomberek
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.

methyl
How do you compare to devenv and devbox? Why would I choose Flox over any of them?
Yanael
Reproducible development environment, I'm very enthusiastic about it and have been using development containers for years now, at work, they do a great job too. About a year ago, I started to hear about Nix. I was super excited at first, the promise is amazing, but the onboarding process has been awful for me. I have a defined development environment I want to achieve, but it seems I always miss something in the way it should be approached. I'm glad to see some new tooling helping to improve the overall experience. Anyway, I keep trying and hope it will click at some point. I'm wondering, at which moment it did for you?
ronef
Thanks for asking! This is definitely a deeper lets get beers convo when you're in the bay! But - Have you ever seen the Microservices video? https://www.youtube.com/watch?v=y8OnoxKotPQ

I was leading the developer products team at Facebook back then and started a project around injecting remote capabilities into local dev. Short of it was that thousands of developers were waiting 45 minutes for cold builds... Part of the initial steps for the project was to map out the entire SDLC (so we can get a sense of what parts of the toolchains we need to rebuild), that's where that video above comes into mind if you look at that whiteboard towards the end... Visualizing how complex we've made it is what got me into the headspace of - this can't actually be how we go about this.

flurie
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 enterprise offering will answer all of my questions.

tomberek
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.
gregwebs
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 the build
I am glad that flox is pushing its development forward. Does flox have a way to run services? With `devenv` I run my database with `devenv up`.
jljljl
Devbox can also run services too. Both products use an awesome process runner called process-compose (https://github.com/f1bonacc1/process-compose/) which is worth checking out (it's even built with nix!)
tripdout
I think the ability to run services is really what separates Devbox from other related Nix-based dev-env solutions.

Essentially taking what you get from the NixOS-specific configuration.nix options (like for example `services.mediawiki.enable = true`) and letting that be per-project, per-directory, is super useful.

mrbonner
+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.
soraminazuki
I use devenv with flakes. That allows me to use standard Nix commands including nix run.
whazor
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.
sisve
Great list.

Using devbox myself and very happy with it.

Would be great to hear what separates flox from the rest.

xwowsersx
I have used devbox and have been keeping an eye on other options. Haven't tried devenv yet. Any thoughts on devenv vs flox given what we're seeing here?
[deleted]
(comment deleted)
tripdout
The more powerful version search that Flox (and other dev env solutions built on Nix) have compared to the regular Nix search is super useful.

Glad that all these different companies are exploring more ways to use Nix and hopefully improvements can be shared throughout the ecosystem.

jahsome
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 seemingly endless already-deprecated methodologies to reach that point. Perhaps I'm just dumb, or looking in the wrong places.

In any case in my experience the end result is every time I see something related to nix, I find myself thinking "I can't wait til that's easy"

tmountain
I love nix and have contributed quite a few packages to the nix repository, and I will vouch that it’s anything but easy. I have a background in Haskell which makes it more familiar, but even the syntax is counterintuitive to newcomers.
xedrac
This is my experience too. At scale, I find Nix to be really slow, and the remote building infrastructure over VPN to be very flakey (see what I did there?). But it does solve some tough problems, and also introduces some new ones. Nix is incredibly useful, and extremely frustrating at the same time. Also, disk space...
jaxr
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 it just gets too much in my way.
SkyMarshal
> 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?

paulhilbert
"Flox began its life during the deployment of Nix at the D. E. Shaw group, where it quickly proved invaluable by making Nix easier for newcomers".

Is that the line you are referring to? Sounds like the opposite of what you suggests it says.

jahsome
The line suggests the opposite yes. That's why I take issue with it.

There's nothing easy about nix. Maybe flox makes it easier, but I am so burned out by screwing around for countless hours with nix I'm not even going to try to figure out if it's true.

bitvoid
I'm confused here. That quote clearly says that Flox makes Nix easier for newcomers, not that Nix is easy. What exactly do you take issue with?
jahsome
The fact that my experience with nix has historically been _so_ difficult, I fear even something that claims to make it "easier" will not be able to deliver -- my aversion has everything to do with nix, and little do with any product which claims to improve it. Consider it guilt by association.

For me, it doesn't simply need to be easier, it needs to be usable. I lack confidence a product which is an abstraction layer is going to solve that for me, because I have a personal inability to understand the underlying system.

emptysongglass
Maybe you need to try it out rather than casting doubts about a product you haven't tried yet? Pre-emptively doubting claims based on your past experience with a tool Flox claims to solve seems like a poor way to go here.

For what it's worth, there are a number of options in the Nix space that really do solve for its complexity like Devbox and now Flox.

jahsome
Maybe I know that but I'm still too damaged to try? That is the entire point of my post.

Thanks for the "advice" though.

kenmacd
If you still use it, my best suggestion is to use a github search for 'path:.nix TERMs' when you run in to issues. It's likely someone already has that custom package, or an overlay to fix that missing compile option, or whatever else it is that you're looking for. I find reading other peoples solutions also helps with understanding and solving related problems.

I'm in no means claiming Nix is perfect, but coming from other distros to NixOS I really appreciate the ability to reboot to a new generation and then reboot back if I run in to issues. To do the same in Arch I had a bunch of 'snapper plus manual steps' to accomplish the same.

aidenn0
I read that as Flox makes nix easier for newcomers, not that nix is easy for newcomers.
rapnie
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/

rochak
Hard agree. I see the advantages but the initial learning curve is incredibly steep. Funny how this mimics my experience with Rust.
phero_cnstrcts
I think once somebody solves the hellish configuration with another language that people can actually understand NixOs will take off. I mean, I hate js as much as everybody else, but I’d rather use that to configure nix than whatever that thing is that they use now.
stevefolta
The language isn't the problem, it's the structure (if you can call it that) of Nixpkgs that makes it so difficult. And no, flakes are not the answer, they may solve composability but they create other problems.
whateveracct
I used the repl from day 1 and it was so intuitive. No other alternative has a repl (besides guix I guess)
ivan_burazin
Hey Ron congrats on the launch! Looking forward to bringing flox to daytona as well.

Love to collab on it when you feel the time is right

Ivan cofounder Daytona.io

zcoyle
Congrats Ron! Glad to see you still at it!