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
Deleted Comment
Oh wow. I really don't see a way to a $2.4B exit here. Good luck!
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"
Is that the line you are referring to? Sounds like the opposite of what you suggests it says.
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.
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?
[0] https://std.divnix.com/
What's your strategy for dealing with the underlying complexities?
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.
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.
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.
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.
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:
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.
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
- 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 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 languageI'm the first to admit that nix is way too cumbersome to use, but this alone doesn't seem like enough value add.
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?
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 Flox have an optional cloud solution as well? Can Flox install specific versions of Nix packages? What about OS-specific dependencies?
I've worked with tools like that for 5 years. Curious to understand what Flox brings to the table that we don't already have.
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 :\
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)
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.
Dead Comment