[HN Gopher] Show HN: Flox 1.0 - Open-source dev env as code with...
___________________________________________________________________
Show HN: Flox 1.0 - Open-source dev env as code with Nix
Hey HN, I'm Ron Efroni, CEO at Flox, and today we are releasing
version 1.0 of our open source CLI, helping folks manage
development environments everywhere.My own experience with
development environments began with air-gapped systems, having to
actually burn software to a CD to iterate over a very slow and
expensive development cycle, sometimes reaching the server rack and
realizing I have the wrong disk.... Fast forward to today and there
are countless alternatives available backed by incredible compute
resources, yet we somehow still find ourselves paying the price of
long development cycles. That's why I've been working for over a
decade to simplify the development stack so we can spend more time
on making 1's and 0's do magical things, and why my co-founder
Michael and I started Flox to bring you the solution based on Nix.
Today is just the first step on that journey. We hope you'll take a
peek at our new release, and very much look forward to continuing
the journey with you from here together! Introducing Flox 1.0
Flox is a platform that lets developers and operators focus on
building fast with reproducible environments that span the
enterprise SDLC. Using a declarative framework based on Nix, a
package management and configuration tool, Flox allows developers
to create environments that contain everything they need to build
software. Why Flox? Flox behaves a lot like your favorite and
familiar package manager, but it allows you to create as many
environments as you want on your machine. Each one can contain a
different combination of packages. Environments are portable by
default. If you install a package inside one that isn't cross-
platform, it's easy to carve out exceptions. It's also easy to
write hooks and populate your environment with variables - we
designed it to be hackable. Flox environments run in user-space,
like, where you are. When you type `ls` after activating a Flox
environment you will see the same stuff because you're in the same
place - even with all those new packages available. No mounting
volumes, no proxying ports. No breaking into the toolset you just
conjured. Getting Started: No sign-ups, just one install away.
Dive into our GitHub repository (https://github.com/flox/flox) and
start exploring I'm around all day to answer questions, talk Nix,
or just reminisce about simpler times ;). Lots of open source
love, Ron
Author : ronef
Score : 266 points
Date : 2024-03-13 15:44 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ivanjermakov wrote:
| What is the benefit of using Flox over plain nix-shell or nix
| develop?
| mrd3v0 wrote:
| Or https://devenv.sh
| slekker wrote:
| or https://www.jetpack.io/devbox/ :^)
| anonzzzies wrote:
| Ah! The modern hell of choice. Can't these peeps just work
| together and make one great thing instead of fragmenting
| over and over? I think I know the answers but have to ask
| anyway, hope to learn.
| zamalek wrote:
| 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.
| smw wrote:
| I think you're discussing direnv, not devenv -- which
| appears to be a direct alternative to Flox
| vhodges wrote:
| 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).
| srid wrote:
| > this doesn't do services, but there was a flake util
| just announced that adds support for that
|
| You must be referring to services-flake:
|
| https://community.flake.parts/services-flake
| OJFord wrote:
| Why `nix develop`, not `nix shell` or `nix profile`?
| Because you're also packaging the final result with nix
| anyway or something?
|
| > nix develop starts a bash shell that provides an
| interactive build environment nearly identical to what
| Nix would use to build installable. Inside this shell,
| environment variables and shell functions are set up so
| that you can interactively and incrementally build your
| package.
|
| I'm not saying it's bad or wrong - it's a long time since
| I've used nix and it's changed/progressed a lot, and I'm
| considering it again so just keen to understand.
|
| edit: also just found shell.nix & nix-direnv integration
| - https://nix.dev/tutorials/first-steps/declarative-
| shell#decl...
| zamalek wrote:
| Nix shell is for devshells declared as a top-level in
| your flake. 99.99% of the time this is identical to the
| primary package, but sometimes having additional things
| around is helpful. E.g. I use justfiles for local dev
| (meaning I have to pull Just in as a dep), but that isn't
| something used for a real package build.
|
| Nix profile is for activating profiles, which even a
| seasoned nix user would have little use for directly.
| It's what underpins home-manager as an example.
| OJFord wrote:
| I suppose what I'm missing then is why you ever need to
| switch from nix shell to (your just etc. -less) nix
| develop environment?
|
| Is it that the latter is for actually building/running
| the debug build locally, like a `docker compose up
| --build` for example? i.e. it's the environment the thing
| you're working on runs in, but you working on it run in
| nix shell (with just, git, docker compose in that
| example, your editor, etc.)?
| mrd3v0 wrote:
| I guess it somewhat follows the Nix tradition of having
| several pieces of software doing the same exact thing and
| confusing the users about which one to pick.
| soraminazuki wrote:
| That's equivalent to demanding the Python community to
| abolish PyPI in favor of making the "one great" standard
| library. Nix is a language after all. It's meant to have
| tools that build on it.
| mkenigs wrote:
| 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 those changes are reflected in TOML.
| Whereas with `nix develop` you have to edit a Nix expression
| - `nix develop` drops you into a bash shell, whereas `flox
| activate` can drop you into a bash or zsh shell (and we plan to
| add support for fish)
|
| - We support using git to manage environments just like nix
| tools do, but we've also added the option to share flox
| environments in ways you can't with any of those tools (flox
| push/flox pull/flox activate -r) and the ability to view
| environments in ways we feel can be more user friendly. If you
| create an account, you can see packages I have in my
| environment at https://hub.flox.dev/mkenigs/default, or if you
| have the CLI, you could inspect my environment with `flox list
| -r mkenigs/default` before using it with `flox activate -r
| mkenigs/default`. I think that's much more digestible than
| linking a flake.nix to someone who doesn't know the Nix
| expression language
| notresidenter wrote:
| You know you can just write `nix develop -c zsh` or `nix
| develop -c fish` or whatever, right?
| tomberek wrote:
| Yes, I'm also a Nix maintainer. `nix develop` does many
| other things, originally based on re-creating the build
| environment of a derivation. This means that it is not
| ideal for the case of development environments that must
| support more than just building.
| notresidenter wrote:
| Interesting, thanks.
| tripdout wrote:
| Does this save environment variables and aliases defined in
| the Nix devshell?
| the_duke wrote:
| So what you are offering here is essentially a small UX
| improvement over sharing a flake with a devshell in a Git
| repo?
|
| I'm the first to admit that nix is way too cumbersome to use,
| but this alone doesn't seem like enough value add.
| eikenberry wrote:
| The value needed by Nix is not more/better tech but an on-
| ramp for people who want to use Nix without learning all
| about all the various ways to do thing. Just having a
| single, opinionated onboarding experience will add a ton of
| value to the project.
| joshcsimmons wrote:
| If you think this is a "small" improvement on Nix's UX you
| clearly have never used Nix.
| shubber wrote:
| 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 whatever's
| next.
|
| Even more important: every abstraction is going to leak. Maybe
| the Flox CLI "looks" cleaner or whatever, but in the end you'll
| still need to learn Nix to use it effectively. Why learn twice
| as much stuff as you need?
| pxc wrote:
| I use Nix at work, to distribute tools to (among other
| places) developers outside my team. I'm also the person
| within my team who knows Nix best.
|
| 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.
| joshcsimmons wrote:
| Does a python developer NEED to know how C works to write
| automation scripts that work reasonably well? This logic is
| silly.
| pxc wrote:
| They don't, but I have respect and sympathy for developers
| who prefer to dig deeper with learning their tools, and how
| that might make them tend to prefer stacks with fewer
| layers sometimes. I think it's a valid concern, especially
| for hobbyist and experimental/autodidactic use cases. In a
| corporate environment or within a team, people typically
| specialize and defer to each other in various areas, so
| maybe it matters less there.
| e3bc54b2 wrote:
| If I understand correctly, the linked repo is for flox CLI
| client. While it is welcome, is there a plan to open source the
| service components? I'd like to deploy flox on my own and have
| portable environments. Otherwise this I'd just another SaaS with
| lock-in and "lots of open source love".
| ronef wrote:
| we will always allow the CLI to stand alone for a local
| developer or CI runner. the service side of Flox is for those
| who want a faster performance, easy sharing, or eventually
| enterprise control. so while the CLI can use the closed service
| it's purely optional (and will always be optional)
| Rucadi wrote:
| I really don't understand why should I use this over plain nix,
| can you elaborate?
| cal85 wrote:
| I just want clean, repeatable environments for different
| projects. I've tried getting into Nix a few times but I always
| get overwhelmed by all the different things it is/does. This
| looks 100x simpler to me.
| Rucadi wrote:
| Hmm...
|
| I understand that if you don't know anything about the
| language or what is a flake, it may be a little bit
| difficult.
|
| But really, adding a new package to your environment once you
| have a flake setup, which a minimal one is trivial, is just
| adding the name of the package.
|
| Here you have a flake.nix example from leptos.
| https://github.com/leptos-rs/leptos/blob/main/flake.nix
|
| You want a new dependency? Add it to buildInputs. (this one
| doesn't have packages setup, but anything in the attribute
| set packages will be available in path)
|
| You want to search a package:
| https://search.nixos.org/packages (or use the cli)
|
| you want to test a package before adding it? nix-shell -p or
| nix shell for example.
|
| Heck, even if you want it more easy, you could write a tool
| in less than 100 lines that adds packages names to
| .json/.yaml/.toml, which allows you to parse it using the nix
| language and a simple cli written with bash functions to
| add/remove packages if you wanted.
|
| That's why it is hard for me to understand this project as a
| product, it seems like a wrapper to the most basic things :\
| malkosta wrote:
| I once needed to install a specific version of a package on
| my nix environment. It took me 2 hours to find how...
|
| After a few months, I needed to do that again, but now the
| project supported devenv.sh. It took me 5 min.
|
| That experience also repeated for other kinds of tasks, for
| example: start postgres (or redis or elasticsearch or
| cassandra...), install packages only if the host system is
| `darwin`, install old versions of packages that aren't on
| the registry anymore, etc...
| Rucadi wrote:
| How does devenv help with using an specific version of a
| package in an easier way than nix (with flakes)? Does it
| have any kind of simpler syntax for overlays? Or you are
| referring to pinning a nixpkgs version?
|
| I'm not really against tools that make it easier to use
| nix, I think devenv is a nice tool and I like that it
| doesn't hide nix, the same way I love home-manager and
| use it all the time.
| malkosta wrote:
| > I like that it doesn't hide nix
|
| Yep. That's my main argument for it against devbox.
|
| > Does it have any kind of simpler syntax for overlays?
|
| Yes, it does. But what helps isn't that, but the concise
| docs with just the information I need to know to get up
| and running quickly: https://devenv.sh/getting-started/
|
| I've read multiple docs/books on Nix, but I always find
| myself lost when I need to accomplish anything simple.
| With devenv, I can spot most of my answers from the docs
| menu. They are all a single click distant from me.
| dataangel wrote:
| I tried NixOS because I needed to recreate an environment
| with a specific GCC version. It was absolute hell, you are
| likely looking back on your experience with rose colored
| glasses now that you know how things work. Even really
| really really basic shit was insane, here's an example: the
| whole system is built on hashes, and there is no consistent
| format for them! I was getting an error with hash A even
| though I explicitly requested hash B, and I couldn't figure
| out why. Turns out nix can't decide whether to use base32
| or base64....
|
| I also tried passing arguments to specify the GCC version
| in like 10 different ways, *that all failed silently*.
| Staying far far far away from Nix even though on paper I
| should love it.
|
| Edit: oh yeah and `nix shell` and `nix-shell` both exist
| and don't do the same thing
| tomberek wrote:
| I understand that Nix solves many problems and indeed bet on
| its ability to do so. It is why I've put so much effort into
| Nix itself.
|
| 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)
| ParetoOptimal wrote:
| Selling coworkers on flox or devenv is way easier than Nix.
| peter_l_downs wrote:
| Hi 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 is your plan?
| ronef wrote:
| 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 Flox Catalog
| that ships with Flox. If you are interested in publishing your
| output or need revised versions of open source packages in Flox
| then it'll be very easy to have your own catalog to compliment
| the always-free Flox Catalog that Flox ships with today. Beyond
| that, we are focused on a number of services that help bring
| Nix's build to the enterprise. Over time we intend to sell a
| solution to enterprises - through subscriptions and services -
| so they can more effectively manage expansive and fragmented
| software supply chains. As part of developing custom tooling
| for enterprises, we think it's reasonable for them to
| participate in funding for that work.
| peter_l_downs wrote:
| Thank you for the answer. Best of luck to you and your
| investors!
| IshKebab wrote:
| Good luck! My experience of Nix, and similar "robust
| engineering" solutions like Bazel is that there are a handful
| of people that get it, and see the benefits. But there are
| hoards more that think you should just write hacky shell
| scripts and bugs don't really matter anyway.
| ceving wrote:
| I do not understand the usecase. If I need a particular
| environment I will install it in LXC.
| dymk wrote:
| That doesn't solve "works on my box" or reproducible builds
|
| Developer environments should be cattle, not pets once you're
| working with more than a few engineers
| ParetoOptimal wrote:
| The default supported developer environment should be cattle
| not pets, but developers should be free to have pets.
| xrisk wrote:
| What's the current relationship of the project with DE Shaw and
| how did you end up making a company on top of this?
| michaelbrantley wrote:
| Thanks for asking! I'm Michael Brantley, Flox CTO and formerly
| responsible for build and release engineering at the D. E. Shaw
| group. The high-level summary can be found in
| https://flox.dev/about but the back story is that I started
| diving into Nix in late 2017, and once I finally understood how
| Nix worked, how amazing the Nix community is and the incredible
| potential of the Nixpkgs collection I immediately realized I'd
| been "doing it wrong" all this time! It was then that we
| embarked on an effort to deploy Nix internally, but soon ran
| into many obstacles to enterprise adoption.
|
| As I'm sure will be similar for many other teams, our Nix
| deployment started life as a series of bespoke applications and
| systems created to address such obstacles, but I suppose the
| difference in our case was that we had an internal venture
| studio called DESCOvery who recognized the impact that it could
| have on devs everywhere, and then worked closely with Ron,
| founding engineer Tom Bereknyei and me to launch the business.
| It's been an awesome journey - we hope you like it, and stay
| tuned for more to come!
| sandGorgon wrote:
| https://news.ycombinator.com/item?id=39616709
|
| a few days back daytona was also released. any thoughts on how it
| differs ?
| ivan_burazin wrote:
| Happy to take this one, as I am one of the cofounder of
| Daytona.
|
| Daytona solves all the automation and provisioning of the dev
| environment, actually wrote an article here laying out exactly
| what we do: https://www.daytona.io/dotfiles/diy-guide-to-
| transform-any-m...
|
| Daytona currently supports only the dev container
| (https://containers.dev/) "dev env infrastructure as code"
| standard, but are looking to support others such as devfile,
| nix and flox.
|
| Hope this helps
| Cu3PO42 wrote:
| Congrats 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 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.ru
| stLibSrc}" export BINDGEN_EXTRA_CLANG_ARGS="$(<
| ${stdenv.cc}/nix-support/libc-crt1-cflags) \ $(<
| ${stdenv.cc}/nix-support/libc-cflags) \ $(<
| ${stdenv.cc}/nix-support/cc-cflags) \ $(<
| ${stdenv.cc}/nix-support/libcxx-cxxflags) \
| ${lib.optionalString stdenv.cc.isClang "-idirafter
| ${stdenv.cc.cc.lib}/lib/clang/${lib.getVersion
| stdenv.cc.cc}/include"} \ ${lib.optionalString
| stdenv.cc.isGNU "-isystem ${lib.getDev
| stdenv.cc.cc}/include/c++/${lib.getVersion stdenv.cc.cc} -isystem
| ${stdenv.cc.cc}/include/c++/${lib.getVersion
| stdenv.cc.cc}/${stdenv.hostPlatform.config} -isystem ${stdenv.cc.
| cc}/lib/gcc/${stdenv.hostPlatform.config}/${lib.getVersion
| stdenv.cc.cc}/include"} \ $NIX_CFLAGS_COMPILE"
|
| 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.
| tomberek wrote:
| > What's your story for dropping down into 'real Nix' if
| required?
|
| 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
| focom wrote:
| Sorry to be this guy, but why is Nix better than a docker dev
| container?
| OJFord wrote:
| On non-Linux it should be faster/less overhead; on all
| platforms I suppose it's just arguably easier/quicker to make
| changes & 'rebuild', and then the result is that that just is
| your environment, it's not a container inside it that you have
| to exec into or run commands through or make your IDE use or
| whatever.
|
| But mostly it's just two different approaches and people will
| be happy to argue about why there's is better, or that they
| don't use either (just the system environment (on a non-NixOS
| system..) as it were).
| ParetoOptimal wrote:
| I mostly agree, but one big thing missing is Nix is
| reproducible by default while docker is only repeatable.
| OJFord wrote:
| Yeah, I was just trying to avoid anything to which you
| could say 'well I can do that with docker [and appropriate
| care & attention]'.
| tomberek wrote:
| It's not necessarily that one is better than another; it can be
| complementary. I tend to think that Nix makes many of the
| reasons to use a container superfluous, but there still remain
| other reasons to use containers.
|
| For example, a talk about using both Docker and Nix (yep,
| that's me ;) ): https://www.youtube.com/watch?v=l17oRkhgqHE
| Rucadi wrote:
| I have to use both at the same time.
|
| I have a Docker with an old version of centos which for some
| reason is the one provided to us.
|
| I then create an "overlay" over it using nix, so I can actually
| use software with newer glibc etc... easily.
|
| Regardless of that, nix is way better than docker, in the sense
| that docker doesn't ensure reproducibility, you can build a
| Dockerfile in two different days, and get different versions of
| packages installed, this is simply not possible with nix, you
| have complete control over your tools.
|
| And if you decide to port your application to a "nix package",
| you have complete control over all the dependencies of you
| application, a reproducible way to build it, and an easy way to
| deploy it.
| stephenr wrote:
| So, I read about a similar-ish tool to this recently, `devenv` -
| it sounds like both tools are based around Nix.
|
| The other article (talking about `devenv`) was discussing a
| migration away from running Vagrant.
|
| I had questions then that I still have now with this tool:
| assuming this, like `devenv` doesn't directly run a VM, how
| exactly do you solve actual platform differences - e.g. it's
| _quite common_ to have developers using macOS or Windows, and
| production servers running a Linux distro.
|
| Sure, some things work the same or close-enough to the same, but
| even with scripting languages (no aot compiling) that have pretty
| good cross platform support, there are differences either in
| features, extensions, or in system level dependencies (i.e. a
| database server, cache server, etc).
|
| Vagrant is one solution to this problem, as is "Docker in a VM",
| albeit a little less flexible IMO - essentially you run a "close
| to production" environment inside a VM, with zero worries about
| what the host environment is, because the software is still
| running in basically the same environment as prod. The rise of
| Arm workstations has made this _interesting_ , but Debian 12 on
| Amd64 is still a heck of a lot closer to Debian 12 on Arm64 than
| it is to macOS or Windows on _anything_.
|
| So what is the Nix solution to this problem?
|
| It _sounds_ like the best you 'd hope for would be to run Nix
| inside a VM, potentially managed by something like Vagrant (thus
| giving you a reproducible VM running a reproducible environment),
| but a number of comments I've seen about using `devenv` or nix
| made a point of "no VM required".. so that just makes me wonder,
| am I missing some vital piece of information about Nix, or are
| these people just running much simpler dev environments than I'm
| used to?
| tomberek wrote:
| Nix runs alongside other distributions in various OSs,
| including OSX. (Windows is being looked at, do not hold your
| breath.)
|
| The cross-platform capability of `flox` comes from our usage of
| Nixpkgs, which includes allowance for some of the differences
| between platforms and makes them less of an issue.
|
| If some piece of software has a specific difference when run on
| different platforms and you rely upon that difference, then
| your need to use that platform in some way: native, VM,
| translator, etc. Nix does make it easier to manage, build,
| distribute, multiple kinds of software.
|
| Flox environments leverage this same foundation to expose the
| same environment on multiple systems and we plan to work on
| this more. What in particular would you be looking for?
| Rucadi wrote:
| Using Nix as a package manager works best with a repository
| called "Nixpkgs".
|
| Nixpkgs focuses on reproducible builds, that means that for the
| same inputs, you always are going to get the same binary
| output.
|
| All of Nixpkgs are built using nixpkgs, and they don't depend
| on any library outside nixpkgs, including glibc and compilers.
|
| That means that you can "lock" your packages into a version,
| and you ensure that it will run the exact same version and
| configuration in all machines that you install it, no matter
| the underlying OS or how old/new it is, glibc problems etc...
|
| This is the power of Nix.
|
| All of this can be done via a simple
|
| Flake.nix -> define the system Flake.lock -> automatically
| generated, defines the exact version of nixpkgs among others.
|
| (Can also be done via channels but flakes are better imo)
| solatic wrote:
| One critical issue with "power of Nix without the learning curve"
| kind of products is that you still have Nix behind the scenes,
| including the /nix/store, which is _intentionally_ not cleaned up
| by Nix automatically. So when users try out something that hides
| Nix from them, their drives inevitably fill up, which is super
| user-friendly because they have no idea how to reduce the amount
| of storage used. It 's different when users understand that
| they're installing Nix, and go through the learning curve,
| because that learning curve helps them to build the mental model
| of what /nix/store is and how to maintain it.
|
| What's your strategy for dealing with the underlying
| complexities?
| anon291 wrote:
| Just set nix garbage collect to run every thirty minutes.
| pasc1878 wrote:
| The point being asked was how do you do the gc using flex, as
| the aim is to not have to go inti nix
| emptysea wrote:
| We have the same problem with bazel at work, after a few months
| your machine is running out of disk space
| dieortin wrote:
| Luckily a feature to limit the disk cache size is in
| development: https://github.com/bazelbuild/bazel/issues/5139
| tomberek wrote:
| Supporting rollback and history means disks can fill up. With
| Nix, this is usually due to a bunch of GC roots pointing to
| profiles and packages that then cannot be cleaned up. Our
| environments are not just symlinks, but have a declarative
| format (under the hood, flakes) so one can remove them, but
| also reproduce them as needed. So GC'ing them is less
| destructive than with using `nix-env`/`nix profile`. This
| allows us to be more aggressive in cleaning up old generations.
|
| So the strategy is to ensure there is always a
| declarative+reproducible way to recover the things you clean
| up, then we can apply various heuristics to avoid disks from
| filling up; free space, age, least-recently-used, least-
| frequently-used - are all being considered.
| colordrops wrote:
| Nix supports garbage collection.
|
| Also there are literally thousands of insanely complex things
| happening behind the scenes every time you use your computer.
| Not sure why Nix is considered special when abstracting over
| it.
| xyzzy_plugh wrote:
| As opposed to Docker, or Bazel?
|
| Conversely I have never had this problem with Nix. It tells you
| plainly how to clean up garbage. It's easy to interrogate to
| find out what's hanging around, and why. The reason it's not on
| by default is that, like any garbage collector, it can be
| disruptive -- there is no "one size fits all" policy.
|
| Ultimately if you have too many gc roots you have to make some
| decisions.
| aidenn0 wrote:
| The problem (especially pre-flakes) with nix (and Docker too;
| haven't used Bazel) is that if you GC, you can't recreate
| your previous environment (which version of nixpkgs were you
| using when you built it/which day did you run apt-get update
| in your Dockerfile).
|
| It appears that Flox uses flakes and versions the flake.lock
| file, so it should be possible to readily reproduce anything
| that hasn't completely disappeared from the internet.
| Cyph0n wrote:
| True, but with Flakes, as long as you didn't upddate your
| lock file, you should always be able to rollback to your
| previous environment.
|
| On NixOS, you can then configure background GC to clean up
| the Nix store periodically: https://search.nixos.org/option
| s?channel=23.11&from=0&size=5...
| Gimpei wrote:
| Would this work as a simpler alternative to Nix home manager?
| tomberek wrote:
| Yes. For limited situations it provides a simpler interface.
| Flox won't provide exactly the same feature set, but there are
| many situations where home-manager is too much.
|
| You can consider the current `flox` environment to be similar
| to a declarative profile, conceptually positioned between home-
| manager and devShells.
| troymc wrote:
| I wonder if something like this could be used instead of conda or
| pixi to manage Python packages, the used-version of Python, the
| Python virtualenv, etc.
| Cu3PO42 wrote:
| It can, but I wouldn't recommend it unless you have native
| dependencies that are just a pain to install. You'll loose
| Windows compatibility, may have to package some Python packages
| yourself, have a learning curve for everyone in the Python
| ecosystem and gain... what exactly?
| tomberek wrote:
| The python ecosystem will require specific support, so at the
| moment we recommend using `flox` to get all of the other things
| that might not be managed by an existing Python package
| manager, and/or to install that package manager itself.
|
| Being a general solution, `flox` cannot directly provide the
| same level of integration as a python-specific tool, but we CAN
| make it easier to use those other tools, and bring in others.
| methyl wrote:
| How do you compare to devenv and devbox? Why would I choose Flox
| over any of them?
| Yanael wrote:
| Reproducible development environment, I'm very enthusiastic about
| it and have been using development containers for years now, at
| work, they do a great job too. About a year ago, I started to
| hear about Nix. I was super excited at first, the promise is
| amazing, but the onboarding process has been awful for me. I have
| a defined development environment I want to achieve, but it seems
| I always miss something in the way it should be approached. I'm
| glad to see some new tooling helping to improve the overall
| experience. Anyway, I keep trying and hope it will click at some
| point. I'm wondering, at which moment it did for you?
| flurie wrote:
| Hello Ron, congratulations to everyone on the team!
|
| It looks like you've pared back some of the more expert
| configurability in order to clean up the UX. I really like the
| environment focus and composability, which is a real pain point
| in the Nix world.
|
| Do you have a plan to add back any of that configurability over
| time? I realize I am probably not your target audience, at least
| as a free user, and perhaps your enterprise offering will answer
| all of my questions.
| tomberek wrote:
| Yes. We have designs to allow for more powerful configuration
| for experts. A good example of this is let people use
| alternative manifest representations; JSON, Nix, etc.
| gregwebs wrote:
| There are several tools in this space now- nix is maturing and
| people are realizing how useful nix can be for dev envs.
| * [devenv](devenv.sh) - I am using it and loving it, but worried
| that the development is not moving forward *
| [devbox](https://www.jetpack.io/devbox) *
| [daytona](https://www.daytona.io/docs/usage/workspaces/) *
| [devshell](https://github.com/numtide/devshell) *
| [bob.build](bob.build) more focused on the build
|
| I am glad that flox is pushing its development forward. Does flox
| have a way to run services? With `devenv` I run my database with
| `devenv up`.
| jljljl wrote:
| Devbox can also run services too. Both products use an awesome
| process runner called process-compose
| (https://github.com/f1bonacc1/process-compose/) which is worth
| checking out (it's even built with nix!)
| tripdout wrote:
| I think the ability to run services is really what separates
| Devbox from other related Nix-based dev-env solutions.
|
| Essentially taking what you get from the NixOS-specific
| configuration.nix options (like for example
| `services.mediawiki.enable = true`) and letting that be per-
| project, per-directory, is super useful.
| jeanregisser wrote:
| Not nix based, but I really like https://github.com/jdx/mise
| too to manage dev tools.
|
| It's a modern version of https://github.com/asdf-vm/asdf
| written in Rust.
| hiljusti wrote:
| Formerly known as `rtx`
| mrd3v0 wrote:
| > but worried that the development is not moving forward
|
| There is an open v1.0 PR:
| https://github.com/cachix/devenv/pull/1005
| mrbonner wrote:
| +1 to devenv. I used to use Nix natively, then switched to
| devbox and then devenv. devenv is the most intuitive to use. I
| just wish that I could just run a command using devenv (similar
| to nix run) instead of having to declare it in the devenv.nix
| first.
| soraminazuki wrote:
| I use devenv with flakes. That allows me to use standard Nix
| commands including nix run.
| whazor wrote:
| Nix allows you to have a single lock file for all your
| dependencies. This is very useful for development environments.
| When you share a lock file via Git, then you know your
| colleagues will be running the same versions.
| sisve wrote:
| Great list.
|
| Using devbox myself and very happy with it.
|
| Would be great to hear what separates flox from the rest.
| codethief wrote:
| How does Flox compare to Devbox? https://github.com/jetpack-
| io/devbox
| tripdout wrote:
| The more powerful version search that Flox (and other dev env
| solutions built on Nix) have compared to the regular Nix search
| is super useful.
|
| Glad that all these different companies are exploring more ways
| to use Nix and hopefully improvements can be shared throughout
| the ecosystem.
| jahsome wrote:
| The line about nix making it easier for newcomers in the readme
| and similar statements always trigger me. I am quite a competent
| person and I've never once thought "that was easy" when trying to
| use nix.
|
| I adore the concepts of nix, but the user experience is awful.
| Maybe that's what this tool solves? It takes a frustrating amount
| of effort and incessant config tweaking with little to no
| documentation and navigating seemingly endless already-deprecated
| methodologies to reach that point. Perhaps I'm just dumb, or
| looking in the wrong places.
|
| In any case in my experience the end result is every time I see
| something related to nix, I find myself thinking "I can't wait
| til that's easy"
| tmountain wrote:
| I love nix and have contributed quite a few packages to the nix
| repository, and I will vouch that it's anything but easy. I
| have a background in Haskell which makes it more familiar, but
| even the syntax is counterintuitive to newcomers.
| jaxr wrote:
| Exact same experience here. Been fiddling with nixos for quite
| a while, but never got comfortable with .nix or flakes. The
| base concepts keep escaping my mind, I have to revisit every
| time I have to configure something new and I just got tired.
| Issues are difficult to debug and you have to go through very
| specific commands and a hellish filesystem to understand what's
| going wrong. I love the concept, but I feel like it just gets
| too much in my way.
| SkyMarshal wrote:
| _> and a hellish filesystem_
|
| What do you mean by this part? The actual filesystem like
| Ext4/ZFS/etc? Or the removal of the unix Filesystem Heirarchy
| and replacement with a simulated/softlinked version in
| Nix/OS?
| paulhilbert wrote:
| "Flox began its life during the deployment of Nix at the D. E.
| Shaw group, where it quickly proved invaluable by making Nix
| easier for newcomers".
|
| Is that the line you are referring to? Sounds like the opposite
| of what you suggests it says.
| aidenn0 wrote:
| I read that as _Flox_ makes nix easier for newcomers, not that
| nix is easy for newcomers.
| rapnie wrote:
| Agreed on the experience, hard to onboard. I looked at
| devenv.sh as easier way to get going. Implemented all with Nix,
| less lock-in. Just found std [0] and that looks quite promising
| too.
|
| [0] https://std.divnix.com/
| rochak wrote:
| Hard agree. I see the advantages but the initial learning curve
| is incredibly steep. Funny how this mimics my experience with
| Rust.
| ivan_burazin wrote:
| Hey Ron congrats on the launch! Looking forward to bringing flox
| to daytona as well.
|
| Love to collab on it when you feel the time is right
|
| Ivan cofounder Daytona.io
| zcoyle wrote:
| Congrats Ron! Glad to see you still at it!
| Evidlo wrote:
| Could we get user-global installs in ~/.local as a sort of
| default environment when no other environment is active?
|
| I'm imagining a usecase as an alternative to `brew` but with the
| power of Nix.
| z_mitchell wrote:
| 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.
| p2hari wrote:
| I saw some alternatives being suggested and wanted to do the same
| (Also, so that I can look back at this item, through my comments
| :) ). Started using https://pkgx.sh/ lately. I know it has some
| baggage with tea.xyz and crypto, but it is also easy to get
| started with.
| j_san wrote:
| flox.dev/terms leads to a 404
| tomberek wrote:
| That link in hub.flox.dev is wrong. The link at
| https://flox.dev/terms-conditions is correct. Fixing....
| thanks!
| abstore wrote:
| https://abstores.ck.page/products/webdevelopment
| nagstler wrote:
| Congrats on the launch, I am building an OSS Reverse ETL project
| called Multiwoven (https://github.com/Multiwoven/multiwoven),
| built on top of many dev tools, frameworks etc. We manage to ship
| it using docker-compose to devs, wondering where does Flox fit
| in, can you help me understand with an use-case while docker
| exists?
| WatchDog wrote:
| How does nix deal with different CPU architectures?
|
| If I have some developers using an ARM based macbook, and some
| devs on an x86_64 based machine, is it easy to support both
| without much maintenance?
| carterschonwald wrote:
| Is there any way to export the associated nix scripts?
| dleink wrote:
| Hi Ron! In ~2000 I drove from south Jersey to deep Long Island
| and only realized while staring at a server rack that I brought
| the bag o' CDs that we used for windows deployments, not *nix.
| Thanks to Robert Moses, the drive in the middle of the night
| actually wasn't that bad!
| starsep wrote:
| Very cool. I will try it out as replacement of nix profile.
|
| flox install/show/search in $HOME looks like way better UX
|
| https://flox.dev/docs/tutorials/layering-multiple-environmen...
| sigmonsays wrote:
| any support for a direnv driven workflow?
| sigmonsays wrote:
| is this a fork of regular nix?
|
| It seems like it might be because they have special instructions
| for nixos users.. kind of makes me affraid to install it tbh.
| LeBit wrote:
| I tried devbox and some other tool in that field.
|
| I then tried dev containers.
|
| Dev containers won. Hands down.
| physPop wrote:
| They're nice, but they lock you into vscode
| LeBit wrote:
| There are more and more tools making use of the dev
| containers spec:
| https://devcontainers.github.io/supporting.html
| jljljl wrote:
| You don't need to choose :). You can use Devcontainers with
| most of the Nix tools, including Devbox. See
| https://containers.dev/supporting
| LeBit wrote:
| I just gave that link to someone else who commented here. :)
|
| You are right, but at the end of the day, I prefer to write
| my own installation scripts or "features" than dealing with
| Nix.
|
| Maybe some day I'll go back to a nix tool to help writing a
| complex devcontainer.json with everything I need.
___________________________________________________________________
(page generated 2024-03-13 23:00 UTC)