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.
(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.
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.
One of the things I really, really love about the way Tweag has approached 'development in the open' with Nix is their series of announcement posts for updates via NixOS Discourse. If Flox can reasonably fit something similar into their strategy, I think that would be huge.
I do so far really like the engagement in all the official Nix communication channels as well as HN. I know you and Rok have both spent tons of time offering help and working with other Nix users in those spaces, and it goes a long way with me to see you guys out here being the ones to answer questions.
Comments
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.
(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.
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.
One of the things I really, really love about the way Tweag has approached 'development in the open' with Nix is their series of announcement posts for updates via NixOS Discourse. If Flox can reasonably fit something similar into their strategy, I think that would be huge.
I do so far really like the engagement in all the official Nix communication channels as well as HN. I know you and Rok have both spent tons of time offering help and working with other Nix users in those spaces, and it goes a long way with me to see you guys out here being the ones to answer questions.