17 ms·

Show HN: Flox 1.0 – Open-source dev env as code with Nix

• codethief 3y ago
  How does Flox compare to Devbox? https://github.com/jetpack-io/devbox https://github.com/jetpack-io/devbox
• focom 3y ago
  Sorry to be this guy, but why is Nix better than a docker dev container?
  • OJFord 3y ago
    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 3y ago
      I mostly agree, but one big thing missing is Nix is reproducible by default while docker is only repeatable.
      • OJFord 3y ago
        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 3y ago
    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 https://www.youtube.com/watch?v=l17oRkhgqHE
  • Rucadi 3y ago
    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.
• catlover76 3y ago
  [dead]
• ivanjermakov 3y ago
  What is the benefit of using Flox over plain nix-shell or nix develop?
  • mrd3v0 3y ago
    Or https://devenv.sh https://devenv.sh
    • slekker 3y ago
      or https://www.jetpack.io/devbox/ https://www.jetpack.io/devbox/ :ˆ)
      • anonzzzies 3y ago
        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 3y ago
          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 3y ago
            I think you're discussing direnv, not devenv -- which appears to be a direct alternative to Flox
          • vhodges 3y ago
            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).
• e3bc54b2 3y ago
  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 3y ago
    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 3y ago
  I really don't understand why should I use this over plain nix, can you elaborate?
  • cal85 3y ago
    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 3y ago
      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 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 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 3y ago
        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...
• peterldowns 3y ago
  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 3y ago
    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.
    • deleted 3y ago
      [deleted]
    • peterldowns 3y ago
      Thank you for the answer. Best of luck to you and your investors!
    • IshKebab 3y ago
      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 3y ago
  I do not understand the usecase. If I need a particular environment I will install it in LXC.
  • dymk 3y ago
    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 3y ago
      The default supported developer environment should be cattle not pets, but developers should be free to have pets.
• xrisk 3y ago
  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 3y ago
    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 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!
• deleted 3y ago
  [deleted]
• sandGorgon 3y ago
  https://news.ycombinator.com/item?id=39616709 https://news.ycombinator.com/item?id=39616709 a few days back daytona was also released. any thoughts on how it differs ?
  • ivan_burazin 3y ago
    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-machine-into-a-codespace https://www.daytona.io/dotfiles/diy-guide-to-transform-any-m... Daytona currently supports only the dev container (https://containers.dev/ https://containers.dev/) "dev env infrastructure as code" standard, but are looking to support others such as devfile, nix and flox. Hope this helps
    • sandGorgon 3y ago
      ahh interesting - so there's a split on the dev format. why did you choose dev containers vs nix ? genuine question - asking because replit makes a big deal of nix, so it seemed to me as a very popular choice.
      • nkko 3y ago
        Dev containers provide a robust standard that is seamlessly integrated into VS Code, which makes workflow smooth end-to-end. Thanks to the Daytona plugin architecture and Apache license, it is relatively easy to bring in more standards. Cause, you know: https://xkcd.com/927/ https://xkcd.com/927/
      • ivan_burazin 3y ago
        You only have so many things you can do at once. From our perspective dev container seemed to be what our target audience was already using; as its supported by VS code natively and also as almost all OSS projects are hosted on Github, and their product Codespaces support it as well - it seemed like the logical first standard. But as mentioned devfile, nix and flox are on the roadmap.
• Cu3PO42 3y ago
  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.rustLibSrc}" 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 3y ago
    > 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
• stephenr 3y ago
  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 3y ago
    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?
  • 3y ago
• solatic 3y ago
  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 3y ago
    Just set nix garbage collect to run every thirty minutes.
    • pasc1878 3y ago
      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 3y ago
    We have the same problem with bazel at work, after a few months your machine is running out of disk space
    • dieortin 3y ago
      Luckily a feature to limit the disk cache size is in development: https://github.com/bazelbuild/bazel/issues/5139 https://github.com/bazelbuild/bazel/issues/5139
  • tomberek 3y ago
    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.
• Gimpei 3y ago
  Would this work as a simpler alternative to Nix home manager?
  • tomberek 3y ago
    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 3y ago
  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 3y ago
    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?
    • amarshall 3y ago
      I don’t use Flox, but do use Nix + poetry2nix for a few Python projects at work. It is a bit of a pain in the ass sometimes, but because it’s Nix, it’s never a pain till something is deliberately changed. The result is that our dev environments are way more reliable than before and project onboarding just works every time. We also use Nix to build for CI and production in these projects.
  • tomberek 3y ago
    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.
• cheif-lama 3y ago
  [dead]
• methyl 3y ago
  How do you compare to devenv and devbox? Why would I choose Flox over any of them?
• Yanael 3y ago
  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?
  • ronef 3y ago
    Thanks for asking! This is definitely a deeper lets get beers convo when you're in the bay! But - Have you ever seen the Microservices video? https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ I was leading the developer products team at Facebook back then and started a project around injecting remote capabilities into local dev. Short of it was that thousands of developers were waiting 45 minutes for cold builds... Part of the initial steps for the project was to map out the entire SDLC (so we can get a sense of what parts of the toolchains we need to rebuild), that's where that video above comes into mind if you look at that whiteboard towards the end... Visualizing how complex we've made it is what got me into the headspace of - this can't actually be how we go about this.
    • Yanael 3y ago
      [dead]
• flurie 3y ago
  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 3y ago
    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 3y ago
  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 3y ago
    Devbox can also run services too. Both products use an awesome process runner called process-compose (https://github.com/f1bonacc1/process-compose/ https://github.com/f1bonacc1/process-compose/) which is worth checking out (it's even built with nix!)
    • tripdout 3y ago
      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.
      • altano 3y ago
        I think Devbox's killer feature is trivially searching for and installing packages by version: https://www.jetpack.io/blog/how-nixhub-searches-nixpkgs/ https://www.jetpack.io/blog/how-nixhub-searches-nixpkgs/
  • jeanregisser 3y ago
    Not nix based, but I really like https://github.com/jdx/mise https://github.com/jdx/mise too to manage dev tools. It’s a modern version of https://github.com/asdf-vm/asdf https://github.com/asdf-vm/asdf written in Rust.
• tripdout 3y ago
  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 3y ago
  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 3y ago
    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.
    • xedrac 3y ago
      This is my experience too. At scale, I find Nix to be really slow, and the remote building infrastructure over VPN to be very flakey (see what I did there?). But it does solve some tough problems, and also introduces some new ones. Nix is incredibly useful, and extremely frustrating at the same time. Also, disk space...
  • jaxr 3y ago
    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 3y ago
      > 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?
• ivan_burazin 3y ago
  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 3y ago
  Congrats Ron! Glad to see you still at it!
• Evidlo 3y ago
  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 3y 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.
• p2hari 3y ago
  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/ 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 3y ago
  flox.dev/terms leads to a 404
  • tomberek 3y ago
    That link in hub.flox.dev is wrong. The link at https://flox.dev/terms-conditions https://flox.dev/terms-conditions is correct. Fixing.... thanks!
• abstore 3y ago
  [dead]
• deleted 3y ago
  [deleted]
• WatchDog 3y ago
  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?
  • lillecarl 3y ago
    The Nix binary cache does x86_64-linux, aarch64-linux, x86_64-darwin, aarch64-darwin and maybe others. Every single package is different, but built from the same source. You won't be sharing binary cache even for python or other interpreted things since they depend on "stdenv" which contains bash. But in practice it's really easy. Though if you're all into robustness you should probably test on the same arch you deploy to eventually.
  • takeda 3y ago
    One way of thinking about Nix is like A Makefile on steroids. It will build what is needed for the right platform. It is also smart enough that you can add cache server and when it needs something that already is in the cache[1] it will download and use binary package seamlessly. Those packages are built from the same sources with same (or almost the same) configuration options and for all intents and purposes should be nearly identical. So while you use your devenv, it will download and use the right packages for your architecture, and if something is missing on the cache server it will build it locally. Now as ARM Mac's are as popular as the intel ones, people are making sure that the packages build on both. [1] nix generates a hash which is based on the package source code, compile options, architecture etc. and uses that for the lookup.
  • pxc 3y ago
    > 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? Yes. I maintain a small collection of Nix packages at my job (some of which come straight from upstream, some of which I've written in-house and are out-of-tree) for use in development and CI environments. We currently support both Intel and Apple Silicon Macs as well as x86_64 Linux environments. There are a couple of small OS-specific tweaks in one or two packages (which we inherit from those packages, which ship OS-specific scripts). There is no architecture-specific code in the repo; I literally never have to think about it. Target platforms are all tested in CI. Deployment targets (users, CI runners) on all supported platforms get the exact same versions of everything, in binary form appropriate to their architecture.
• carterschonwald 3y ago
  Is there any way to export the associated nix scripts?
• dleink 3y ago
  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 3y ago
  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-environments/ https://flox.dev/docs/tutorials/layering-multiple-environmen...
• sigmonsays 3y ago
  any support for a direnv driven workflow?
• sigmonsays 3y ago
  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 3y ago
  I tried devbox and some other tool in that field. I then tried dev containers. Dev containers won. Hands down.
  • physPop 3y ago
    They're nice, but they lock you into vscode
    • LeBit 3y ago
      There are more and more tools making use of the dev containers spec: https://devcontainers.github.io/supporting.html https://devcontainers.github.io/supporting.html
  • jljljl 3y ago
    You don't need to choose :). You can use Devcontainers with most of the Nix tools, including Devbox. See https://containers.dev/supporting https://containers.dev/supporting
    • LeBit 3y ago
      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.
      • lillecarl 3y ago
        https://news.ycombinator.com/item?id=39697259 https://news.ycombinator.com/item?id=39697259 "But there are hoards more that think you should just write hacky shell scripts and bugs don't really matter anyway."
        • LeBit 3y ago
          The link doesn't open on my side. Yeah, I am aware writing my own scripts isn't ideal, but this is the current state of affair. I could use mise to install most tools though. I would need to figure out what the overhead would be.
• physPop 3y ago
  why not use nix shell and direnv?
• ildjarn 3y ago
  Last I tried to use Nix there was lots of confusion over flakes - some tutorials suggested using them and others saying they are still in development. Has the situation improved?
  • takeda 3y ago
    I believe so, it seems like almost all (or all?) solutions listed here: https://news.ycombinator.com/item?id=39696038 https://news.ycombinator.com/item?id=39696038 use flakes underneath. I think the flakes problem come from two things: - flakes are labelled experimental for years now (I think it might be almost 5 years now) which creates confusion with new users, but they are universally used nearly everywhere now - there seems to be some bad blood[1] between https://determinate.systems/ https://determinate.systems/ company and the long time Nix users and developers who are accusing them that they are using Nix for their benefit with not contributing back. From my understanding Determinate Systems introduced flakes and probably this why there's some resistance to it by some. But to answer your question, pretty much everyone adopted flakes and guides that don't use them are most likely old. [1] https://discourse.nixos.org/t/introducing-flakehub/32044 https://discourse.nixos.org/t/introducing-flakehub/32044
    • grhmc 3y ago
      DetSys founder here :). Firstly, congratulations to Flox on the launch. DetSys is founded by Nix's inventor Eelco, and me -- a fairly long time community member (since ~2016.) We're also loaded with long term Nix users and contributors. We (the company) didn't invent flakes, and I didn't have anything to do with it either. While working at Tweag, Eelco worked with Target to develop the idea. I'm not sure where this idea of bad blood or not contributing back comes from, either. The vast, vast majority of our code and products are completely FOSS, and our most popular product (the Determinate Nix Installer) is deliberately licensed in a way that upstream Nix can take it and integrate it however they want, any time they want. And I hope they do! We also invest heavily in contributions directly upstream. We're long time open source contributors and advocates, and that doesn't change now that we started a company. I think there is a lot of compression of time and history here that has lead to lot of pretty baseless accusations and confusion. I think some people who don't like the change don't like it because they've built their own mechanisms to get what flakes provides. That's fine, nobody has to use flakes. The old ways aren't going away. Some folks don't like them because they're not technically perfect or bug-free. That's fine, too, but they're not becoming more stable by pretending flakes don't exist. I look at threads like the one you linked as evidence we're doing something interesting. Nobody would care if what we were doing was useless. One point that is absolutely true, though: DetSys is 100% contributed to the version of the future where Nix + Flakes is the thing. Flakes solve such vast problems that I feel there is no going back. This is the basis for the Determinate Nix Installer: we guarantee flake stability, and use the installer as the wedge to keep that promise with our users. This promise has been the basis of our work on FlakeHub and our just-launched-today FlakeHub Cache. Unfortunately, nix.dev -- an official Nix documentation source -- specifically does not teach much about Flakes. To the degree of introducing documentation for unmaintained tools that see very low community adoption: https://nix.dev/guides/recipes/dependency-management https://nix.dev/guides/recipes/dependency-management. We've taken a strong position on flakes by introducing our installer and zero-to-nix.com, a flake-first documentation source because of this confusion. I have asked numerous times for the various Nix leadership teams to make a choice on if flakes are the future or not, but as we can all plainly see: they have not chosen to do so. This confusion about flakes comes from the very top, unfortunately. I find this very motivating for building the best Nix company I can, to support the adoption of Nix and flakes in interesting places around the world.
• mrbonner 3y ago
  Huge user friendly! Even more than devenv which I’m currently using. One question: does Flox need Nix preinstalled? I don't see any mention of Nix in the installation guide. If Fkox doesn't need Nix install it would be a huge game changer.
  • tomberek 3y ago
    `flox` needs Nix to function. So the rpm/dev/OSX installers first install Nix, and then installs flox itself. If you have Nix already, you can try it out as described here: https://flox.dev/docs/install-flox/#install-with-existing-nix-installation https://flox.dev/docs/install-flox/#install-with-existing-ni.... side-note: with further improvements to Nix as a library, it may be possible to make installing Nix not necessary for flox to function, but this is on a longer time horizon... don't hold your breath
• larusso 3y ago
  Not to bash on the product but I really see the POC here. Nix itself already provides most of the benefits. https://mynixos.com/ https://mynixos.com/ has a similar proposition but concentrates more about full system replication. So please tell me what the differences are.
• bionhoward 3y ago
  What made you choose the GPL license for this?
  • takeda 3y ago
    Thanks for pointing it out, it made me look closer at it. I normally would actually welcome GPL, because it allows to keep project being open source. Though looks like project also comes with CLA where anyone who contributes surrenders their copyright to FloxDev, Inc. What this means, is that no one can fork it and make from it a commercial product. Many would say this is great as it can keep the project open source, except the CLA gives FloxDev, Inc. option to change license at any moment to whatever they want, including making the project fully closed source. I don't think such project can be called open source. It feels like a Trojan horse to fool developers (kind of what Hashicorp did). I mean it is the right, but if you're contributing to it, you're not contributing to Open Source project but volunteering free work to another company.
• danhudlow 3y ago
  What I desperately want is the generation of a lock file so that environment installs are cryptographically guaranteed to be repeatable byte-for-byte. I recognize that this means either checksums every platform supported, but I’ve been startled that none of the options I’ve found seem to have the capacity for this.
  • lytedev 3y ago
    I think you're looking for Nix flakes proper! This is one of the promises! Given so, this means many tools based on nix provide this too, though it's not as easily surfaced.
    • danhudlow 3y ago
      Unfortunately, neither nix flakes nor tools based on nix that don’t “easily surface” this feature provide the security guarantees I’m seeking, since security guarantees are a function of cryptographic proofs and abstractions that are comprehensible to an end user.
• mikenikles 3y ago
  How does it compare to the existing Devbox project (https://www.jetpack.io/devbox https://www.jetpack.io/devbox)? Does Flox have an optional cloud solution as well? Can Flox install specific versions of Nix packages? What about OS-specific dependencies? I've worked with tools like that for 5 years. Curious to understand what Flox brings to the table that we don't already have.
• akho 3y ago
  How does installing by semver work? Do you bring in relevant nixpkgs versions? How do I run some github dude's fork? Or apply my own patches? What's the workflow where a language package manager is involved?
  • benfutor 3y ago
    Hi! Flox employee here and pulled from our Head of Product: Flox will match the most compatible Nixpkgs version given the declaration in the manifest. We are working on a robust service to allow better searching across time to dramatically expand the amount of software available. We're working on a few solutions to this--allowing flake references in the Flox manifest and offering a robust solution as a product feature. Flox is compatible with language specific package manager--and provides suggestions and auto detection of existing package managers. You can use the Flox shell hook to initialize the project in the language specific package manager of choice and Flox will suggest this to you if it sees you're using a known package manager (such as requirements.txt for pip, yarn.lock for yarn, etc). Hope this helps
• vrnvu 3y ago
  I tested the product on both Ubuntu and MacOS, but had a frustrating experience in both cases. I prefer using Fish, but it's not supported. So, I uninstalled it and tried with Bash or Zsh instead. Even after completely removing Fish from my system, the flow CLI still insists it's there and tries to open a path that no longer exists. Switching to Zsh gave a different result, but it was still a frustrating experience. While I could activate the flox environment the first time I executed it, exiting caused issues. I had to reactivate it multiple times, encountering errors such as "environment already enabled" before it finally worked properly. I'm sorry for the negative feedback, but this seems far from a version 1.0 product user experience.
  • benfutor 3y ago
    Sorry you had a frustrating experience. It's definitely us missing the mark. Re: fish, saw you found the issue someone else opened on it. We have it on our plan and will be adding support soon https://github.com/flox/flox/issues/1173 https://github.com/flox/flox/issues/1173 Re: your zsh experience, it's hard to judge exactly what's happening from your comment but we have had other users where the state of activation was suppressed by themes which can cause "environment already active". https://github.com/flox/flox/issues/637 https://github.com/flox/flox/issues/637 - if you think it's something else or have more detail to share, let us know (either here, github, anywhere). Thanks for trying Flox! (Flox employee here)
    • vrnvu 3y ago
      Thanks for answering. I like the ideas behind nix and flox, and I ack it's not an easy problem. I'll keep my eye on the project and check again in the future. GL.
• subins2000 3y ago
  Please reduce/remove the animations in the website, while scrolling down it's laggy
• pxc 3y ago
  I tried Flox on macOS last night and noticed that it installed Nix in the default profile alongside the one Nix-Darwin manages in /run/current-system/sw/bin, and symlinked its copy into /usr/local/bin. I also noticed that there were no instructions for existing Nix users qua Nix users— nothing for NixOS users or users of other distros who might already have Nix installed but who lack a Flox-supported distro package format. Is this because as a third-party profile manager for Nix, Flox depends on the unstable format of Nix profile manifests and whatever else, or is Flox actually usable (if not tested) alongside a wide range of Nix versions? Is Nix-based installation of Flox a feature you intend to eventually support? Also, it's been mentioned that Fish support is coming. Can anyone point me to a bit of Flox source or config on where the shell integration for the `activate` subcommand actually lives? I'd like to rig something up with fenv or the like while awaiting official Fish support, but didn't see an obvious place to plug in when I glanced at my Flox install and the Flox source last night.
  • mkenigs 3y ago
    Hey there! Looks like you may have missed the Nix/Generic and Nix/NixOS tabs at https://flox.dev/docs/install-flox/ https://flox.dev/docs/install-flox/? Do those satisfy the side by side use case you’re talking about? I think the best way to use fish at the moment is `FLOX_SHELL=zsh flox activate -- fish`. That doesn’t support aliases but should mostly work Are you hoping to actually hack on the source or just trying to understand how to come up with a workaround? We error for any shell other than bash or zsh somewhere around https://github.com/flox/flox/blob/9e18a3ceaa185006bae95a482723055ffcdc5fd4/cli/flox/src/commands/environment.rs#L566 https://github.com/flox/flox/blob/9e18a3ceaa185006bae95a4827... If you want to take a crack at hacking on it I’d be more than happy to give more background!
    • pxc 3y ago
      > Hey there! Looks like you may have missed the Nix/Generic and Nix/NixOS tabs at https://flox.dev/docs/install-flox/ https://flox.dev/docs/install-flox/? Do those satisfy the side by side use case you’re talking about? I totally did! Those are what I was looking for. (Although I'm glad I missed them in a way because I'm happy to have gotten to explore the behavior of the Flox installer when there's an existing Nix install already.) How embarrassing! Thanks :) > I think the best way to use fish at the moment is `FLOX_SHELL=zsh flox activate -- fish`. That doesn’t support aliases but should mostly work Thanks! I'll try that for sure. > Are you hoping to actually hack on the source or just trying to understand how to come up with a workaround? More the latter, especially because I don't totally know yet how interested I am in Flox. But I do love Fish and I did once work on some hairy issues in shell initialization for Fish in NixOS, so this kind of shell environment setup is the kind of thing that I've enjoyed plugging away at in the past, haha. At the same time I have virtually no Rust experience. That link is already pretty helpful, since I have a sense of where the shell code finally comes in, now. But I am curious about how the thing works, and I miiiiiight try to mess around, so if the shell init stuff is something you've worked on and are proud of/excited to share about, I'd love to hear more about it!
• Cchalop1 3y ago
  Very cool !
• zero0529 3y ago
  Is this similar to Devbox by jetpack.io ?