z_mitchell
Joined 7 years ago
Karma
14
Submissions
12
Member since
May 15
Recent submissions
Comment · 1 year ago
Comment · 1 year ago
Not really :) (disclosure: I work there)
1. "sugared up nix pkgs" -> Nixpkgs is a package repository, and also not the product here. We provide a tool for setting up and using reproducible developer environments via a familiar, approachable CLI. You can install things from nixpkgs, and the experience is "sugared up" in the sense that in my opinion it's more palatable to most people than using Nix itself. I've used Nix for years, and I use NixOS and nix-darwin to configure my machines, but there's too much friction for me to want to use it for development all the time.
2. "for money" -> everything you see in the product today is free and will remain free. We're developing enterprise features that won't be free. That said, I use Flox today for all of my local development on side projects and it does quite literally everything I need.
The bigger picture is that we use Nix under the hood as a layer of primitives/infrastructure but make different choices about how to put them together and deliver features that Nix doesn't have out of the box like services (or something similar to docker-compose), the ability to use more than just Bash, etc. The goal is to allow more people to bring Nix to work: https://flox.dev/blog/its-time-to-bring-nix-to-work/
Happy to answer other questions
Comment · 1 year ago
https://flox.dev/docs/cookbook/languages/rust/
That describes how to get set up with Rust. Long story short, cargo depends on a linker and brings it along, but doesn’t expose it to other programs via PATH. If there are build scripts that call out to rustc or a linker directly then you need to explicitly install one. This is intentional, but yeah it can be surprising when you get an error about not finding a linker.
You also need libiconv on macOS for reasons, but all of this is described in the link above.
Comment · 1 year ago
There’s a small number of us working on the docs and we actually just did a pass over them before the holidays to evaluate how well they help users get things done. We took some action items from that that we’ll be working in over the next few months.
That said, the repo is public[1] and if there’s specific things you’d like to see or would find helpful you could open an issue. That would be really helpful, but there’s obviously no obligation to do so.
Comment · 1 year ago
It uses Nix under the hood.
I would argue that Nix does not make trivial environment setup easy. One of the reasons I love Flox for my own development is that I can just "flox install" packages. That doesn’t really exist for project-specific packages with Nix ("nix profile install" exists, but that installs globally). I would say give Flox a try and see if you actually run into issues. If you do, we're pretty good about fixing them as they come up.
It has also not been my experience at all that Nix packages are "often unmaintained and simply broken." I use Nix every day for work, and I use it to configure all of my personal machines (on both macOS NixOS). Can't say that's ever really been a problem for me.
Comment · 1 year ago
I think that's a bit reductive, but I get the intent. A lot of people see systemic problems in their development and turn to tools to reduce the cognitive load, busywork, or just otherwise automate a solution. For example "we always argue over formatting" -> use an automated formatter. That makes total sense as long as managing/interacting with the tool is less work, not just different work.
With Nix I still think it's a net positive, but the "different kind of work" side of the equation is pretty large. That's why we're building Flox [1]. The imperative user interface of a package manager (flox install, flox search, etc) that builds out a declaratively-configured, reproducible, cross-platform developer environment. I really think it nails the user experience by keeping that "different work" side of the equation small, and (I hope) just gets out of your way.
[1]: https://flox.dev
Comment · 1 year ago
Hey, I'm actually the author and a Flox engineer. I don't use anything else for my personal projects these days, no plain Nix and no containers.
One of the posts that I link the article describes an environment used to make proctrace (https://github.com/zmitchell/proctrace), which includes both Rust and `bpftrace` for the tool itself, and some Node stuff for the documentation site.
For Rust development specifically it's a little more setup than without Flox because a typical `rustup` install gives you everything by default, whereas the Rust packages are distributed individually in the Flox Catalog (e.g. install `cargo` and `rustc` separately). That's due to how Nixpkgs packages Rust tools, and we'll probably provide a more ergonomic situation in the future. The only other real downside for Rust development is if you need to compile for a different target than the host machine e.g. wasm. You would need to write a flake that provides those toolchains and add that flake to your manifest.
That sounds like a lot of caveats and extra work, but that's because I’m long winded and have nothing else to really complain about. I have a Rust environment that I pushed to FloxHub, and then I pull a copy of it into each new project. I only needed to set it up once (which was easy) for it to work everywhere since it's reproducible and cross-platform by default.
Comment · 2 years ago
Author here, thanks for posting it u/thunderbong XD
Comment · 2 years ago
Flox employee here, you can do that by creating an environment in your home directory and activating it in your `.bashrc` or `.zshrc` (we don’t support fish yet, but it’s on the roadmap). An environment created in your home directory is called `default` and your question is exactly its intended purpose.
Comment · 7 years ago
Author here. Be warned, this was just a proof of concept that I did because I thought it would be fun/weird/interesting!
- cd into repo
- `flox activate` -> puts you into a subshell with your desired tools, environment variables, services, and runs any setup scripts you've defined
- You do your work
- `exit` -> you're back in your previous shell
Setting up and managing an environment is also super easy:
- cd into project directory
- `flox init` -> creates an "environment"
- `flox install python312` -> installing new packages is very simple
- `flox edit` -> add any environment variables, setup scripts, services in an editor
- `flox activate` -> get to work
The reason we call these "environments" instead of "developer environments" is that what we provide is a generalization of developer environments, so they're useful in more than just local development contexts. For example, you can use Flox to replace Homebrew by creating a "default" environment in your home directory [2]. You can also bundle an environment up into a container [3] to fit Flox into your existing deployment tools, or use Flox in CI [4].
All that stuff I described is free, but we have some enterprise features in development that won't be, and I think people are going to find those very appealing.
[1] https://flox.dev
[2] https://flox.dev/docs/tutorials/migrations/homebrew/
[3] https://flox.dev/docs/reference/command-reference/flox-conta...
[4] https://flox.dev/docs/tutorials/ci-cd/