Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Flox 1.0 – Open-source dev env as code with Nix (github.com/flox)
382 points by ronef 8 months ago | hide | past | favorite | 193 comments
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




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?


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.


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.


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.


Thank you for the answer. Best of luck to you and your investors!


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


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"


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


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.


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?


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.


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.


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.


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.


I read that as Flox makes nix easier for newcomers, not that nix is easy for newcomers.


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.


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


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.


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


Hard agree. I see the advantages but the initial learning curve is incredibly steep. Funny how this mimics my experience with Rust.


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/


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.


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.


There is garn a typescript frontend to the nix language. https://github.com/garnix-io/garn/


I used the repl from day 1 and it was so intuitive. No other alternative has a repl (besides guix I guess)


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?


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.


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.


True, but with Flakes, as long as you didn’t upddate your lock file, you should always be able to rollback to your previous environment.

On NixOS, you can then configure background GC to clean up the Nix store periodically: https://search.nixos.org/options?channel=23.11&from=0&size=5...


Can't you just pin pkgs to particular commit, so everything will have the version it did as of that commit?


Right, but traditional nix doesn't make that easy (which is why niv and flakes exist).


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


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.


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.


We have the same problem with bazel at work, after a few months your machine is running out of disk space


Luckily a feature to limit the disk cache size is in development: https://github.com/bazelbuild/bazel/issues/5139


Just set nix garbage collect to run every thirty minutes.


The point being asked was how do you do the gc using flex, as the aim is to not have to go inti nix


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.


> 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


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


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?


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.




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.


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.


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


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


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


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'


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


I think you're discussing direnv, not devenv -- which appears to be a direct alternative to Flox


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


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.


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.


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?


How does it compare to the existing Devbox project (https://www.jetpack.io/devbox)?

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 really don't understand why should I use this over plain nix, can you elaborate?


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 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 :\


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


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


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.


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


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


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)


Selling coworkers on flox or devenv is way easier than Nix.


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?


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.


I tried Flox on macOS last night and noticed that it installed Nix in the default profile alongside the one Nix-Darwin manages in /run/current-system/sw/bin, and symlinked its copy into /usr/local/bin. I also noticed that there were no instructions for existing Nix users qua Nix users— nothing for NixOS users or users of other distros who might already have Nix installed but who lack a Flox-supported distro package format.

Is this because as a third-party profile manager for Nix, Flox depends on the unstable format of Nix profile manifests and whatever else, or is Flox actually usable (if not tested) alongside a wide range of Nix versions? Is Nix-based installation of Flox a feature you intend to eventually support?

Also, it's been mentioned that Fish support is coming. Can anyone point me to a bit of Flox source or config on where the shell integration for the `activate` subcommand actually lives? I'd like to rig something up with fenv or the like while awaiting official Fish support, but didn't see an obvious place to plug in when I glanced at my Flox install and the Flox source last night.


Hey there! Looks like you may have missed the Nix/Generic and Nix/NixOS tabs at https://flox.dev/docs/install-flox/? Do those satisfy the side by side use case you’re talking about?

I think the best way to use fish at the moment is `FLOX_SHELL=zsh flox activate -- fish`. That doesn’t support aliases but should mostly work

Are you hoping to actually hack on the source or just trying to understand how to come up with a workaround? We error for any shell other than bash or zsh somewhere around https://github.com/flox/flox/blob/9e18a3ceaa185006bae95a4827... If you want to take a crack at hacking on it I’d be more than happy to give more background!


> Hey there! Looks like you may have missed the Nix/Generic and Nix/NixOS tabs at https://flox.dev/docs/install-flox/? Do those satisfy the side by side use case you’re talking about?

I totally did! Those are what I was looking for. (Although I'm glad I missed them in a way because I'm happy to have gotten to explore the behavior of the Flox installer when there's an existing Nix install already.) How embarrassing! Thanks :)

> I think the best way to use fish at the moment is `FLOX_SHELL=zsh flox activate -- fish`. That doesn’t support aliases but should mostly work

Thanks! I'll try that for sure.

> Are you hoping to actually hack on the source or just trying to understand how to come up with a workaround?

More the latter, especially because I don't totally know yet how interested I am in Flox. But I do love Fish and I did once work on some hairy issues in shell initialization for Fish in NixOS, so this kind of shell environment setup is the kind of thing that I've enjoyed plugging away at in the past, haha. At the same time I have virtually no Rust experience. That link is already pretty helpful, since I have a sense of where the shell code finally comes in, now.

But I am curious about how the thing works, and I miiiiiight try to mess around, so if the shell init stuff is something you've worked on and are proud of/excited to share about, I'd love to hear more about it!


Yes I have worked on it and would love to help if you want to poke around! If you have more questions I can answer on our Slack https://go.flox.dev/slack. It's not completely straightforward how it all works


Last I tried to use Nix there was lots of confusion over flakes - some tutorials suggested using them and others saying they are still in development.

Has the situation improved?


I believe so, it seems like almost all (or all?) solutions listed here: https://news.ycombinator.com/item?id=39696038 use flakes underneath.

I think the flakes problem come from two things:

- flakes are labelled experimental for years now (I think it might be almost 5 years now) which creates confusion with new users, but they are universally used nearly everywhere now - there seems to be some bad blood[1] between https://determinate.systems/ company and the long time Nix users and developers who are accusing them that they are using Nix for their benefit with not contributing back. From my understanding Determinate Systems introduced flakes and probably this why there's some resistance to it by some.

But to answer your question, pretty much everyone adopted flakes and guides that don't use them are most likely old.

[1] https://discourse.nixos.org/t/introducing-flakehub/32044


DetSys founder here :). Firstly, congratulations to Flox on the launch.

DetSys is founded by Nix's inventor Eelco, and me -- a fairly long time community member (since ~2016.) We're also loaded with long term Nix users and contributors. We (the company) didn't invent flakes, and I didn't have anything to do with it either. While working at Tweag, Eelco worked with Target to develop the idea.

I'm not sure where this idea of bad blood or not contributing back comes from, either. The vast, vast majority of our code and products are completely FOSS, and our most popular product (the Determinate Nix Installer) is deliberately licensed in a way that upstream Nix can take it and integrate it however they want, any time they want. And I hope they do! We also invest heavily in contributions directly upstream. We're long time open source contributors and advocates, and that doesn't change now that we started a company.

I think there is a lot of compression of time and history here that has lead to lot of pretty baseless accusations and confusion. I think some people who don't like the change don't like it because they've built their own mechanisms to get what flakes provides. That's fine, nobody has to use flakes. The old ways aren't going away. Some folks don't like them because they're not technically perfect or bug-free. That's fine, too, but they're not becoming more stable by pretending flakes don't exist.

I look at threads like the one you linked as evidence we're doing something interesting. Nobody would care if what we were doing was useless.

One point that is absolutely true, though: DetSys is 100% contributed to the version of the future where Nix + Flakes is the thing. Flakes solve such vast problems that I feel there is no going back. This is the basis for the Determinate Nix Installer: we guarantee flake stability, and use the installer as the wedge to keep that promise with our users. This promise has been the basis of our work on FlakeHub and our just-launched-today FlakeHub Cache.

Unfortunately, nix.dev -- an official Nix documentation source -- specifically does not teach much about Flakes. To the degree of introducing documentation for unmaintained tools that see very low community adoption: https://nix.dev/guides/recipes/dependency-management.

We've taken a strong position on flakes by introducing our installer and zero-to-nix.com, a flake-first documentation source because of this confusion. I have asked numerous times for the various Nix leadership teams to make a choice on if flakes are the future or not, but as we can all plainly see: they have not chosen to do so. This confusion about flakes comes from the very top, unfortunately. I find this very motivating for building the best Nix company I can, to support the adoption of Nix and flakes in interesting places around the world.


Ah, apologies for getting things wrong. Thanks for explaining it and making it clearer. I just saw the hostility in that thread and that's how I interpreted it.

BTW: I have nothing to do with Flox, I'm just ordinary Nix user who actually likes flakes and also wishes it would get removed from the experimental flag. At this point I agree there's no going back. If flake was removed tomorrow there would be a huge uproar and countless of setups broken. The ship already has sailed and continuing on keeping it behind experimental only undermines what "experimental" supposed to mean.


I don’t know anyone who is recommending against flakes these days. The “experimental” label is more about the API stability than completeness, bugginess, or anything else.

There are certain scenarios where the performance can be problematic, but there are workarounds and permanent solutions are being worked on. Nevertheless, using flakes extensively at home and work.


>I don’t know anyone who is recommending against flakes these days. The “experimental” label is more about the API stability than completeness, bugginess, or anything else.

"Experimental" traditionally means "if you use it and it breaks, then that's your fault". This is because if <experimental thing> did break, the entire internet would dogpile on any complainers with "IT WAS LABELLED EXPERIMENTAL WHAT WERE YOU EXPECTING."

It's the same as ignoring Kickstarter warnings; if a project gives you a warning then tell you to ignore that same warning, don't; if things go to shit then everyone will say "YOU WERE WARNED WHAT WERE YOU EXPECTING." They cannot un-warn you, that's not how this social situation works. I'm not claiming this is fair, I'm just claiming this is how it plays out in practice.

The only safe response to this is to assume that anything labelled "experimental" is exactly what it says. And to be clear, that means the only safe response is to ignore any claims that the thing labelled "experimental" is safe.

Or to put it another way: if you don't mean it's experimental and do recommend it to the average user, then don't use the term "experimental".


Here's the closest thing to an 'unwarning' that can exist, which is a tl;dr of the history:

The experimental label is a historical compromise because flakes, which was conceived by the original author of Nix (who is still a maintainer), was a major change merged to master without going through the whole Nix community RFC process (which was then in its infancy).

So it was added, but tucked away behind an 'experimental' designation and enablement flag. This proved controversial at the time and perhaps still is among old timers, but in the interim flakes have become enormously popular with new users (probably most people who picked up Nix in the past 3 years or so).

Third-party adoption of flakes has by now reached the point that the vast majority of big tools in the Nix ecosystem support it well. Some interfaces are still officially unstable but serious breakage is pretty rare. The flakes implementation in the codebase is very usable but still incomplete and still a bit buggy, and straightening out the kinks in the implementation as well as stabilizing the interfaces (both for Nix code and the CLI) is careful, patient work under way right now.

Hence the common recommendation to just use 'em unless you have deep Nix knowledge and a specific reason not to.


See: A plan to stabilize the new CLI and Flakes incrementally https://github.com/NixOS/rfcs/pull/136


How do you compare to devenv and devbox? Why would I choose Flox over any of them?


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?


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)


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


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?


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


What I desperately want is the generation of a lock file so that environment installs are cryptographically guaranteed to be repeatable byte-for-byte. I recognize that this means either checksums every platform supported, but I’ve been startled that none of the options I’ve found seem to have the capacity for this.


I think you're looking for Nix flakes proper! This is one of the promises!

Given so, this means many tools based on nix provide this too, though it's not as easily surfaced.


Unfortunately, neither nix flakes nor tools based on nix that don’t “easily surface” this feature provide the security guarantees I’m seeking, since security guarantees are a function of cryptographic proofs and abstractions that are comprehensible to an end user.


I tested the product on both Ubuntu and MacOS, but had a frustrating experience in both cases.

I prefer using Fish, but it's not supported. So, I uninstalled it and tried with Bash or Zsh instead.

Even after completely removing Fish from my system, the flow CLI still insists it's there and tries to open a path that no longer exists.

Switching to Zsh gave a different result, but it was still a frustrating experience. While I could activate the flox environment the first time I executed it, exiting caused issues. I had to reactivate it multiple times, encountering errors such as "environment already enabled" before it finally worked properly.

I'm sorry for the negative feedback, but this seems far from a version 1.0 product user experience.


Sorry you had a frustrating experience. It's definitely us missing the mark.

Re: fish, saw you found the issue someone else opened on it. We have it on our plan and will be adding support soon https://github.com/flox/flox/issues/1173

Re: your zsh experience, it's hard to judge exactly what's happening from your comment but we have had other users where the state of activation was suppressed by themes which can cause "environment already active". https://github.com/flox/flox/issues/637 - if you think it's something else or have more detail to share, let us know (either here, github, anywhere).

Thanks for trying Flox!

(Flox employee here)


Thanks for answering.

I like the ideas behind nix and flox, and I ack it's not an easy problem.

I'll keep my eye on the project and check again in the future. GL.


Huge user friendly! Even more than devenv which I’m currently using.

One question: does Flox need Nix preinstalled? I don't see any mention of Nix in the installation guide. If Fkox doesn't need Nix install it would be a huge game changer.


`flox` needs Nix to function. So the rpm/dev/OSX installers first install Nix, and then installs flox itself.

If you have Nix already, you can try it out as described here: https://flox.dev/docs/install-flox/#install-with-existing-ni....

side-note: with further improvements to Nix as a library, it may be possible to make installing Nix not necessary for flox to function, but this is on a longer time horizon... don't hold your breath


How does nix deal with different CPU architectures?

If I have some developers using an ARM based macbook, and some devs on an x86_64 based machine, is it easy to support both without much maintenance?


> If I have some developers using an ARM based macbook, and some devs on an x86_64 based machine, is it easy to support both without much maintenance?

Yes.

I maintain a small collection of Nix packages at my job (some of which come straight from upstream, some of which I've written in-house and are out-of-tree) for use in development and CI environments. We currently support both Intel and Apple Silicon Macs as well as x86_64 Linux environments.

There are a couple of small OS-specific tweaks in one or two packages (which we inherit from those packages, which ship OS-specific scripts). There is no architecture-specific code in the repo; I literally never have to think about it.

Target platforms are all tested in CI. Deployment targets (users, CI runners) on all supported platforms get the exact same versions of everything, in binary form appropriate to their architecture.


One way of thinking about Nix is like A Makefile on steroids. It will build what is needed for the right platform. It is also smart enough that you can add cache server and when it needs something that already is in the cache[1] it will download and use binary package seamlessly.

Those packages are built from the same sources with same (or almost the same) configuration options and for all intents and purposes should be nearly identical.

So while you use your devenv, it will download and use the right packages for your architecture, and if something is missing on the cache server it will build it locally.

Now as ARM Mac's are as popular as the intel ones, people are making sure that the packages build on both.

[1] nix generates a hash which is based on the package source code, compile options, architecture etc. and uses that for the lookup.


The Nix binary cache does x86_64-linux, aarch64-linux, x86_64-darwin, aarch64-darwin and maybe others. Every single package is different, but built from the same source. You won't be sharing binary cache even for python or other interpreted things since they depend on "stdenv" which contains bash.

But in practice it's really easy. Though if you're all into robustness you should probably test on the same arch you deploy to eventually.


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.


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.


How does Flox compare to Devbox? https://github.com/jetpack-io/devbox


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.


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?


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.


I saw some alternatives being suggested and wanted to do the same (Also, so that I can look back at this item, through my comments :) ). Started using https://pkgx.sh/ lately. I know it has some baggage with tea.xyz and crypto, but it is also easy to get started with.


Not to bash on the product but I really see the POC here. Nix itself already provides most of the benefits. https://mynixos.com/ has a similar proposition but concentrates more about full system replication. So please tell me what the differences are.


Very cool. I will try it out as replacement of nix profile.

flox install/show/search in $HOME looks like way better UX

https://flox.dev/docs/tutorials/layering-multiple-environmen...


What’s the current relationship of the project with DE Shaw and how did you end up making a company on top of this?


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!


Hi Ron! In ~2000 I drove from south Jersey to deep Long Island and only realized while staring at a server rack that I brought the bag o' CDs that we used for windows deployments, not *nix. Thanks to Robert Moses, the drive in the middle of the night actually wasn't that bad!


Please reduce/remove the animations in the website, while scrolling down it's laggy


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.


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


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)


https://news.ycombinator.com/item?id=39616709

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


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


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.


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.


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/


How does installing by semver work? Do you bring in relevant nixpkgs versions?

How do I run some github dude's fork? Or apply my own patches?

What's the workflow where a language package manager is involved?


Hi! Flox employee here and pulled from our Head of Product:

Flox will match the most compatible Nixpkgs version given the declaration in the manifest. We are working on a robust service to allow better searching across time to dramatically expand the amount of software available.

We're working on a few solutions to this--allowing flake references in the Flox manifest and offering a robust solution as a product feature.

Flox is compatible with language specific package manager--and provides suggestions and auto detection of existing package managers. You can use the Flox shell hook to initialize the project in the language specific package manager of choice and Flox will suggest this to you if it sees you're using a known package manager (such as requirements.txt for pip, yarn.lock for yarn, etc).

Hope this helps


Could we get user-global installs in ~/.local as a sort of default environment when no other environment is active?

I'm imagining a usecase as an alternative to `brew` but with the power of Nix.


Flox employee here, you can do that by creating an environment in your home directory and activating it in your `.bashrc` or `.zshrc` (we don’t support fish yet, but it’s on the roadmap). An environment created in your home directory is called `default` and your question is exactly its intended purpose.



Would this work as a simpler alternative to Nix home manager?


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.


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


I tried devbox and some other tool in that field.

I then tried dev containers.

Dev containers won. Hands down.


You don't need to choose :). You can use Devcontainers with most of the Nix tools, including Devbox. See https://containers.dev/supporting


I just gave that link to someone else who commented here. :)

You are right, but at the end of the day, I prefer to write my own installation scripts or "features" than dealing with Nix.

Maybe some day I'll go back to a nix tool to help writing a complex devcontainer.json with everything I need.


https://news.ycombinator.com/item?id=39697259

"But there are hoards more that think you should just write hacky shell scripts and bugs don't really matter anyway."


The link doesn't open on my side.

Yeah, I am aware writing my own scripts isn't ideal, but this is the current state of affair.

I could use mise to install most tools though. I would need to figure out what the overhead would be.


Ah! I was able to open the link in a proper browser. I'm using HACK on iOS.

Thanks for the condescending comment.


They're nice, but they lock you into vscode


There are more and more tools making use of the dev containers spec: https://devcontainers.github.io/supporting.html


Is there any way to export the associated nix scripts?


is this a fork of regular nix?

It seems like it might be because they have special instructions for nixos users.. kind of makes me affraid to install it tbh.


Is this similar to Devbox by jetpack.io ?


What made you choose the GPL license for this?


Thanks for pointing it out, it made me look closer at it.

I normally would actually welcome GPL, because it allows to keep project being open source.

Though looks like project also comes with CLA where anyone who contributes surrenders their copyright to FloxDev, Inc.

What this means, is that no one can fork it and make from it a commercial product. Many would say this is great as it can keep the project open source, except the CLA gives FloxDev, Inc. option to change license at any moment to whatever they want, including making the project fully closed source.

I don't think such project can be called open source. It feels like a Trojan horse to fool developers (kind of what Hashicorp did). I mean it is the right, but if you're contributing to it, you're not contributing to Open Source project but volunteering free work to another company.


Congrats Ron! Glad to see you still at it!


why not use nix shell and direnv?


any support for a direnv driven workflow?


Very cool !


flox.dev/terms leads to a 404


That link in hub.flox.dev is wrong. The link at https://flox.dev/terms-conditions is correct. Fixing.... thanks!


Sorry to be this guy, but why is Nix better than a docker dev container?


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


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.


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


I mostly agree, but one big thing missing is Nix is reproducible by default while docker is only repeatable.


Yeah, I was just trying to avoid anything to which you could say 'well I can do that with docker [and appropriate care & attention]'.


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


Not nix based, but I really like https://github.com/jdx/mise too to manage dev tools.

It’s a modern version of https://github.com/asdf-vm/asdf written in Rust.


Formerly known as `rtx`


> but worried that the development is not moving forward

There is an open v1.0 PR: https://github.com/cachix/devenv/pull/1005


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.


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


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.


I think Devbox's killer feature is trivially searching for and installing packages by version: https://www.jetpack.io/blog/how-nixhub-searches-nixpkgs/


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


I use devenv with flakes. That allows me to use standard Nix commands including nix run.


Great list.

Using devbox myself and very happy with it.

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


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?


I do not understand the usecase. If I need a particular environment I will install it in LXC.


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


The default supported developer environment should be cattle not pets, but developers should be free to have pets.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: