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
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?
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:
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.
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 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 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.
Has the situation improved?
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 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.
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.
"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".
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.
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!
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!
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?
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)
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.
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 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.
Given so, this means many tools based on nix provide this too, though it's not as easily surfaced.
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.
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)
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.
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.
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
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.
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.
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.
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.
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.
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!
flox install/show/search in $HOME looks like way better UX
https://flox.dev/docs/tutorials/layering-multiple-environmen...
Glad that all these different companies are exploring more ways to use Nix and hopefully improvements can be shared throughout the ecosystem.
a few days back daytona was also released. any thoughts on how it differs ?
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
I'm imagining a usecase as an alternative to `brew` but with the power of Nix.
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?
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
You can consider the current `flox` environment to be similar to a declarative profile, conceptually positioned between home-manager and devShells.
Love to collab on it when you feel the time is right
Ivan cofounder Daytona.io
I then tried dev containers.
Dev containers won. Hands down.
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.
It seems like it might be because they have special instructions for nixos users.. kind of makes me affraid to install it tbh.
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.
For example, a talk about using both Docker and Nix (yep, that's me ;) ): https://www.youtube.com/watch?v=l17oRkhgqHE
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.
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).
* [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`.It’s a modern version of https://github.com/asdf-vm/asdf written in Rust.
There is an open v1.0 PR: https://github.com/cachix/devenv/pull/1005
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.
Using devbox myself and very happy with it.
Would be great to hear what separates flox from the rest.
Developer environments should be cattle, not pets once you’re working with more than a few engineers