The Flox Open Beta
floxdev.com
The Flox Open Beta
1–10 of 59 posts
Re: The Flox Open Beta
#2> flox provides an imperative (and delightful) CLI experience that will seem more familiar to most developers.
So, to be clear: your product is an imperative compositional layer on top of a declarative compositional layer for managing imperative system configuration? Sounds like a hard sell to anyone who doesn't use Nix. Even as a NixOS daily driver, I'm having a hard time understanding how Flox is more than a few shell aliases and a hosted backend.
Re: The Flox Open Beta
#3I just finished reading the announcement on NixOS Discourse here: https://discourse.nixos.org/t/flox-first-open-release-beta/2...
It includes the following:
> We strive to improve the experience of consuming packages from nixpkgs by providing a layer that records their evaluation, build, and cache metadata. We call this layer - a catalog. This allows users of flox to select from multiple versions of packages. It also enables enterprise users to share packages in binary form without exposing their source code or even their Nix expression.
This sounds in some ways pretty similar to something I'd been imagining for Nix, particularly for the purpose of grabbing package definition sources which have been known to work for a given version or range. (The use case is automatically grabbing or generating packages for given semantic versions instead of by Nixpkgs hash.)
I'm interested to see what all they've done with the catalog, and I wonder if it will ever be brought to Nix proper. If that were likely, they would have been developing this in the open, right? (Maybe not! Getting consensus is hard... I do see that the catalog itself and some related work is up on GitHub.)
Re: The Flox Open Beta
#4[dead]
Re: The Flox Open Beta
#5I don't use Nix. Curious if folks can see applying Flox to supercharge interoperability and deployment.
Re: The Flox Open Beta
#6> flox provides an imperative (and delightful) CLI experience that will seem more familiar to most developers. So, to be clear: your product is an imperative compositional layer on top of a declarative compositional layer for managing imperative system configuration? Sounds like a hard sell to anyone who doesn't use Nix. Even as a NixOS daily driver, I'm having a hard time understanding how Flox is more than a few sh…
(i'm on the flox team): A major point of feedback we got from non-Nix users were that they wanted something similar to other package managers. So we looked at the primary differences and focused on designing a user experience with few show-stopping blockers for initial adoption. The goal is to guide people into the declarative side and a gentle introduction to the Nix language and ecosystem.
> Even as a NixOS daily driver, I'm having a hard time understanding how Flox is more than a few shell aliases and a hosted backend.
That's exactly how this started, to "smooth out the rough edges" of Nix. Some of our changes are also being up-streamed into Nix itself, so these aliases and the wrapping can become thinner over time and we can turn our focus to the feature sets that enterprises and organizations want. We are still iterating on:
- easy access to semantic versions - access to a Catalog where each package is known to be built and cached - opinionated nix expression structure - make it easier for users to publish their own software for others to re-use - CLI interface provide interaction with the user - platform native installers (no more `curl | sh`) that use the upstream installer under-the-hood
As a teaser for things on our road-map: - imagine writing a Nix expression that is as simple as a Dockerfile - easy access to transforming your environments, packages, and derivations into different formats - opt-in centralized management of environments - visibility into the environments used by team members and colleagues - optimize AllTheThings(tm)
The most important thing to note is that this is our foray into developing flox in the open and we value all the feedback, thoughts, and especially criticisms.
Re: The Flox Open Beta
#7I just finished reading the announcement on NixOS Discourse here: https://discourse.nixos.org/t/flox-first-open-release-beta/2... It includes the following: > We strive to improve the experience of consuming packages from nixpkgs by providing a layer that records their evaluation, build, and cache metadata. We call this layer - a catalog. This allows users of flox to select from multiple versions of packages. It also…
> This sounds in some ways pretty similar to something I'd been imagining for Nix, particularly for the purpose of grabbing package definition sources which have been known to work for a given version or range. (The use case is automatically grabbing or generating packages for given semantic versions instead of by Nixpkgs hash.)
Yes, this is something users often expect. We make this more efficient than grabbing a unique Nixpkgs hash for each package, which would mean lots of downloading and disk usage for each one - instead our catalog lets you bypass that need.
> I'm interested to see what all they've done with the catalog, and I wonder if it will ever be brought to Nix proper.
Some of the ideas need design iteration before it would be proper to bring into Nix. Some building blocks have already been incorporated (eg: eval-store, impure-derivations and fetch-closure were funded and inspired by flox).
What portions are of greatest interest?
Re: The Flox Open Beta
#8> flox provides an imperative (and delightful) CLI experience that will seem more familiar to most developers. So, to be clear: your product is an imperative compositional layer on top of a declarative compositional layer for managing imperative system configuration? Sounds like a hard sell to anyone who doesn't use Nix. Even as a NixOS daily driver, I'm having a hard time understanding how Flox is more than a few sh…
(i'm on the flox team): A major point of feedback we got from non-Nix users were that they wanted something similar to other package managers. So we looked at the primary differences and focused on designing a user experience with few show-stopping blockers for initial adoption. The goal is to guide people into the declarative side and a gentle introduction to the Nix language and ecosystem. > Even as a NixOS daily d…
[deleted]
Re: The Flox Open Beta
#9While Flox does improve the Nix UX, I don't think that's the most exciting thing about it. The real impact is in bringing the underlying power of Nix to people who would have never used it.
Nix has all sorts of core portability, security and management capabilities that are massively valuable in a distributed and diverse env dev team, but are rarely used because they're too hard.
If Flox takes off, many more developers would benefit from those capabilities, and most of those would still have minimal to know understanding of the underlying Ni complexity.
FWIW, that's at least why I invested in them ;)
Re: The Flox Open Beta
#10This is pretty cool. How should I be thinking about Flox from an SBOM perspective vs. existing vendors? Are auditors really (respectfully) sophisticated enough to appreciate reproducibility guarantees? Esp given other build systems (a la Bazel) make this claim too