* 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?
That's the end of the line for me, sadly.
Regardless, I'd like to fix the scenario you are in. Would you be willing to send in some logs or details?
Disclosure -> Ron here, co-founder at flox and NixOS Board Member
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.
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.
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).
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.
Would you be willing to give us a challenge in a form of example environment that your data analysts/engineers would use with only a `flox pull`?
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.
Edge Dev on Windows 11 25290
https://i.imgur.com/2VjXnQI.mp4
Yikes.
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.
Good luck to the team!
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.)
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?
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.
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.
> 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.
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.
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.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.
Also, having the processes run on the host and filesystem is great for usability.
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 ...'
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!
Whats next on the roadmap?
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 ;)