While 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.
> 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.)
> 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).
I will have a better idea of this after I've had a chance to play with the software! Unfortunately that may be in about a week.
Naively: I think a DB of successful builds and what Nix functions/files produced the working packages and at what versions could be really useful to things like dream2nix or nix-init. (I think that CLI for one-off installs has considerable value itself.)
For my present use cases (perhaps not future ones at my org!) the cases enabling distribution of binary artifacts without publishing sources are not of great interest. For me, those fall into the enterprise-y bucket.
> 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.
* I love that there's a .deb. Usually it's either a GH binary, or curlbash.
* I love the uninstallation instructions. Everyone else doesn't give a shit what they leave all over my filesystem.
* I can't really install it because I don't have Nix, and I don't really know how to get Nix on Ubuntu. I tried some packages once, but they didn't work. I'd appreciate some help here, as Flox is a non-starter if people can't install Nix. It doesn't even mention that I need Nix, the deb just fails to install. This is a pretty big omission.
EDIT: Turns out it fails because I already had Nix? The systemd unit needed to be removed. That's odd.
* I tried to follow the "first environment example", immediately got an error:
error: could not set permissions on '/nix/var/nix/gcroots/per-user' to 755: Operation not permitted
No guidance on how to proceed from here. That directory is already 755. Googling the error leads me to a GitHub issue with hundreds of comments, and no obvious solution other than somehow reinstalling, but I don't think I installed Nix in the first place?
Handling all cases of pre-existing Nix installations, (multi-user, single-user, incomplete, broken, etc) is something we are trying to improve. There is also upstream community work going into improving this experience and we will adopt that as it becomes available. The .deb installs Nix for you, so your best bet is to remove the existing installation (https://nixos.org/manual/nix/stable/installation/installing-...) and try the native installer.
Regardless, I'd like to fix the scenario you are in. Would you be willing to send in some logs or details?
I tried, but I need to create an account, enter my name, a password, my email, wait for the email, click on the activation link, and then wait for a moderator to approve me. This feels like too much effort when I could go to GitHub and upload a file, so I don't think I'll manage it by the time a moderator gets around to approving me.
Thank you for pointing this out! I apologise for the inconvenience and oversight; it is a setting I forgot to update when we launched which has now been fixed.
Thanks for sharing and apologies, will work on improving the Windows / Edge experience. If you want to find out what flox is about, the docs are probably a better place: https://floxdev.com/docs
Appreciate the approach in taking my report seriously.
Seems the animate:requestAnimationFrame fn in the header and footer (headerBoid.js,footerBoid.js) animations are locking some UI threads (adding too many events on stack?).
Firefox seems fine, and I was able to get the gist of the product.
Seems like a good problem to solve, especially for companies that offer libraries (ex: Samsung Tizen dev. environment) or education/enterprises that have a lot of students/interns, as setting up the environment properly could be a significant chunk of the time spent learning/working.
This looks great! I'm interested to know what is the path forward to create revenue from this product? I would hesitant to adopt a tool like this that would go belly up when the money runs dry.
Very good question. How will we make money? What is our monetization strategy? We have nothing to hide here. Our monetization is focused on increasing corporate and organizational use.
1. We love Nix and what we can do with it.
2. We also know that it is not easy to learn or adopt Nix.
3. Even if learning Nix would be easier, adoption of new tech becomes harder the bigger the organisation.
4. The bigger the organisation, the “weirder” their requirements (from the perspective of an open source project). Not all of those requirements make sense to include in an open source version, but would make a big difference for enterprise adoption.
5. We want to make it possible for you (the Nix user) to be able to bring Nix-based technology to your organizations and to be an effective ambassador.
6. Enterprises require a different set of features than anyone else; and they will pay for them.
Hi there! You'll see a number of announcements and releases over the next 3-8 months, as we continue to develop and evolve our open source release, and build tools for enterprise. flox is deeply integrated and committed to the open source nix community. The CEO of flox, Ron Efroni is on the nixos foundation board. Our work intends to be compatible with nix, and so we think this foundation will help people have some long term security if they invest in adopting flox.
flox will continue to be active in contributing to, and supporting and growing the nix community, while also growing a complimentary open source flox community.
We see a few tools that do a similar built-on-top-of-Nix approach, so we released a Rust library that makes using the "command line API" in a more type-safe manner: https://github.com/flox/runix
It's exciting to see so much starting to be built with and on top of Nix. We've been working on enabling developers to go beyond the developer environment and into the later stages of the flow. Curious to get your thoughts on what you find the most compelling from the core Nix story/benefits.
Disclosure -> Ron here, co-founder at flox and NixOS Board Member
> It's exciting to see so much starting to be built with and on top of Nix.
It seems like the majority of names I recognize for their contributions from the Nix ecosystem from the past 8 or 9 years are working not just with, but on Nix/Nixpkgs in a professional capacity now, and the trend is continuing.
The list of companies with Nix people on staff has expanded well beyond just Nix consultancies, into cloud-centric SaaS providers, Enterprise software vendors, companies that make developer tools, etc., etc.
It's hard to imagine that with this new capacity for dedication in so many of the most long-standing, prolific, and passionate Nix contributors, that the Nix ecosystem is not poised to grow and mature by leaps and bounds!
Imo, the key will have to be in continuing to nurture an integral community in the face of all these companies now trying to grow Nix and build on top of it in their own, perhaps sometimes conflicting directions. It's a problem all collaborative projects face, and not one entirely new to Nix— there are just more resources in play now. If the Nix community can manage that during this phase, I think there can be no doubt that wonderful things are ahead.
I started from using asdf [1] for managing golang, python and node. My main language is golang but often I need to run project from other language and different version especially python with packages have different version needed from pip i.e python 3.6 and python 3.8
I found about nix and it looks a good fit for my usecase because it not messing with PATH and not spawning container like docker but when I try to use it, I feel overwhelmed by it.
I use devbox now because it's easy to use but definitely will try flox. I welcome any tools that can help reduce nix complexity.
We think the ability to hopscotch between projects and ecosystems without fear is a key value proposition of Nix-based technologies. Our approach is to address the entire user experience from installation and docs all the way to developing, building, publishing, orchestrating, and sharing your software. It is not all ready - we can't do all of it at once; we are laying down the framework.
Please give us a try and offer any feedback, we want to make it easy to adopt for even non-Nixers and enterprise.
Agreed! flox environments are purpose-built for repeatability: Nix-based, versioned-controlled, shareable with others via git. Check out the docs https://floxdev.com/docs for how to get started with environments. We have a native Mac installer as well.
We're also working on the ability to manage processes and services locally, stay tuned :)
So it's kind of like machine configuration as code, with Nix doing the heavy lifting.
That sounds interesting. However, I wonder how it deals with scenarios like using "flox pull" to do an initial setup, then manually installing something, then months later trying to reconcile what the code says should be installed and what's actually installed.
Which dependencies are you usually combining when you are developing?
I think you may really like flox, because flox will "lock in" the exact cryptographic hashes of the items you have installed and configured. So with flox, it becomes completely reproducible. Yet, you can still use the basic tools that you typically use to develop software (IDE, build tools, makefiles etc).
Have you used Nix? As far as I know, you can't manually install something, at all. You need to add it to the Nix config for it to go in the environment.
You could make it look like manually installing but have it change the definition of the environment, like NPM does with package.json. It wouldn't be distinguishable for someone who doesn't care about Nix.
I tried once before on Mac, but never could get it working properly.
My impression of Nix on Mac is that it doesn't have exclusive control of your system, so it would be possible to install something outside of its control loop.
This 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
This looks pretty interesting. I'm a lead software eng at a startup that is onboarding N number data analysts/engineers and on the face of it this seems like it'd be a great utility to help tame the craziness of python for them.
I think you are right. Plus it's a great way to integrate needed dependencies in other languages, and pin them to the exact version you need. When you need to deploy, you can actually use flox on the production machine, and "flox install", or you can load the flox package into a docker container image and deploy that way too. I developed a Django app for about 2 months with flox, which included postgresql,redis, and several python3 pypi package deps. It was one of the best and most coherent experiences I have had. I also used nix (which flox is based on) to do elixir and phoenix development for several years. flox has taken away many of the pain points (disclaimer, I am employed at flox)>
Oh interesting... yeah this is exactly what i'm looking to do, well Flask not Django but basically the same thing. Question, were you using pycharm at all? Did you have a good method on having that run a file from within a flox env?
The simplest way to get started is to choose the python dependency manager of your choice (could be pip, poetry, etc). You can install this with flox, and then `flox develop` and these dependencies will just be available on your path. You can then launch pycharm from this context, check "which python" in the shell where you ran `flox develop` and add that to your python evaluator in your IDE.
There are more advanced methods to work with python (that will also still work with pycharm, vscode etc) that are discussed in our docs.
Do you think it would be beneficial if we created some guides to configuring common IDE to work with flox environments?
Sure thing. A big part of the workflow that we're developing depends on a variety of tools beyond just python packages. We've got things like dbt, prefect etc in the mix. Being able to specifically set up that set of tools for a project, as well as the right version of Python and sub dependencies like pip would be really helpful. A lot of these tools are easily installed with homebrew but then then issue is that they're global, and if you need version N for Project Y but Version N+1 for Project X then you're out of luck. Also as a sibling comment said i can use those some dependencies to build a container from.
I saw that you can layer environments when you activate, is it possible to have an env build on a another one/require another one? I'm thinking we'd have our standard company env which would have common utilities such as DBT or Gum installed but then we could easily layer over that with project specific dependencies.
You can definitely pin down the specific versions of all your dependencies per environment. And, you can for sure build one environment on top of another, you just have to activate them all (or include them in your project if you take a project based approach)
I know that this has been asked in past threads but I would love to understand how Nix compares to containers and on top of that what does flox provide in it's comparison to containers?
1. A more reproducible environment thanks to nix determinism
2. A more widely re-usable base approach in the form of environments vs containers
with flox, you can develop software in a development environment that matches the way the software will be packaged. Then, you can distribute this software so that someone can just run "flox install" on Mac, Linux, Windos WSL2, or it can be loaded into a docker container image and deployed that way.
FROM python
FROM nodejs
RUN sh -c 'python ... | node ...'
Imagine this Dockerfile being valid. We want to express the idea of composing these two images into one and using binaries from both. Consider that those might have conflicting /usr/lib contents?! This is easy with flox+nix because that conflict doesn't happen.
There are other benefits such as:
- minimal containers
- automatic extraction of artifacts and their runtime-dependencies
- no more pushing your compilers into prod
- no cleaning steps (apt-cache clean)
- declarative
- reproducible
- more fun!
Focus on user feedback, making the developer experience golden for the CLI.
Continue to work on widespread Nix community efforts/projects.
Then on the product side, expand to provide an even more integrated solution for developers who want to work within teams or even small companies, largely, "bringing Nix to work".
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 ;)