What is the benefit of using Flox over plain nix-shell or nix develop?
Flox employee here! To start off by addressing how this relates to nix tools: - Our goal is to be more user friendly. You don't have to learn the Nix expression language or understand nix internals to be successful. - We've been able to add some opinionation and polish. Some of that is subjective, but some examples are: - We have a hybrid imperative/declarative interface. You can `flox install && flox list`, and thos…
Show HN: Flox 1.0 – Open-source dev env as code with Nix
21–30 of 201 posts
Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix
#22I really don't understand why should I use this over plain nix, can you elaborate?
However, Nix poses a relatively steep learning curve being built up from first principles making it very general. Flox aims at simplifying this by narrowing the problem field and providing specialized abstractions and interfaces for those who want to benefit from nix' capabilities without needing to becoming a nix expert at day 0.
(flox employee)
Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix
#23Hi Ron, congratulations on the release. My question is: how will you make money? I see you are the CEO, there is a company, and you have employees. Crunchbase links to news articles that make it seem like you've raised $24MM. Maybe I'm just missing it, but I can't see any pricing information on your landing page or in your docs. After I log in to FloxHub with my Github profile, I don't see any billing options. What i…
Appreciate the call out. Regarding pricing, bringing forward what you saw today for free and open source, was a major part of why I started Flox, with much more to come into it. What we released today will be free forever (both the open source client and the FloxHub services for sharing environments). We plan on expanding the offering to include a more robust private software catalogs that layers on top of the OOTB F…
Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix
#24Earlier quoted context omitted.
Devenv and devbox are completely different. Devenv will merely automatically install envars into your env from a plugin (one of which handles nix). If you aren't using devenv you are missing out, irrespective of whether you use nix. Devbox is a direct alternative to Flox. Edit: all incorrect, I got confused. There are indeed to many of these Nix wrappers.
I think you're referring to direnv as opposed to devenv.sh which does compete in the same space. Numentide was working on one too. I am using devenv.sh at work, at home I just nix develop (but this doesn't do services, but there was a flake util just announced that adds support for that I need to check out).
You must be referring to services-flake:
Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix
#25What is the benefit of using Flox over plain nix-shell or nix develop?
Put another way, I would think that individual engineers would be better off learning the underlying tech and the tools provided that go with them. I think it's very possible that Flox (or devenv or...) reaches EOL, or ceases to track nixpkgs appropriately, or any of the other ways that software rots. Where nix develop is going to last as long as Nix Flakes do, and there's incentive to provide a migration path to wha…
We're currently using devenv.sh to present a prettier interface to those users, who are developers. I don't expect those devs to learn much about Nix, but I do expect to some extent to be responsible for educating and supporting them as issues inevitably come up.
I've not really tried Flox (now that I can do so without any signups and the CLI tool is open-source, I'm more seriously tempted to dig in than before!). But for me, the proposition isn't really learning 2 things vs. 1 or even asking other people to do so. The question is which interface is going to be easier for me to support— my expectation is that if/when things go awry, I'll end up relying on the same Nix knowledge either way. So I don't really see Flox changing what the developers I support are expected to master, but if Flox is something that developers I support find convenient and pleasant to use, I can imagine it reducing UX and documentation work I have to do with the Nix-based tooling I'm gluing together. It may also save me infrastructure burdens, in terms of setting up shared binary caches or helping users share environment configs and Nix code.
I'd really love to support a developer so obsessive and curious that they felt the need to learn and master Nix because they were using Flox as a dependency of my project. I'd like to think that as someone who knows my way around the Nix ecosystem, I could make exploring how Nix works and how Flox adds to it fun for them. But I can also imagine being that developer and feeling annoyed at the prospect of 'having' to learn two tools. I hear that.
Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix
#26a few days back daytona was also released. any thoughts on how it differs ?
Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix
#27I love Nix. I really do. I also recognize the onboarding experience is bad at best and terrible at worst.
As such I welcome any effort to make it more approachable. I believe the imperative CLI is a great step in that direction. It's much closer to what many people expect and will feel comfortable with. Simplifying the "using an environment from somewhere else" story is also one I strongly relate to.
One thing I'm not seeing that I think would be important is IDE integration. Starting your IDE from the command line inside the environment is not intuitive to many of my colleagues and is something I've diagnodes as the root cause of an issue more than once.
What's your story for dropping down into 'real Nix' if required? I'm a bit afraid that this might drop you off at a cliff for somewhat more complicated environments, for example to set up a cross-compilation Rust toolchain.
To stick with the example of Rust development, I have the following shellHook in one of my Flakes:
export LIBCLANG_PATH="${pkgs.llvmPackages.libclang.lib}/lib"
export RUST_SRC_PATH="${pkgs.rust.packages.stable.rustPlatform.rustLibSrc}"
export BINDGEN_EXTRA_CLANG_ARGS="$(
It was necessary to get Rust-Analyzer to play nice. How would I ever set something like this up in Flox? Is this kind of setup something you want to abstract away? If not, how would this ever be discoverable to a user that isn't familiar with Nix?Please don't mistake these questions as me saying this can never work. I really want it to work, I just don't know how yet.
Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix
#28I do not understand the usecase. If I need a particular environment I will install it in LXC.
Developer environments should be cattle, not pets once you’re working with more than a few engineers
Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix
#29Re: Show HN: Flox 1.0 – Open-source dev env as code with Nix
#30Congrats on the launch! I love Nix. I really do. I also recognize the onboarding experience is bad at best and terrible at worst. As such I welcome any effort to make it more approachable. I believe the imperative CLI is a great step in that direction. It's much closer to what many people expect and will feel comfortable with. Simplifying the "using an environment from somewhere else" story is also one I strongly rel…
We already have talked about this and plan to allow using Nix itself in those cases where someone needs the additional power. The current thought is to have allow a either a reference to a flake for specific fields or to have an Nix-style entrypoint.
This is not yet exposed or documented. Stay tuned.
aside: absolutely agree that there is a fine line between hiding complexity and exposing power