Show HN: Flox 1.0 – Open-source dev env as code with Nix • Hacker News Board

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

#191

Post by pxc » Fri, Mar 15, 2024, 5:54 PM UTC

WatchDog wrote: post #109

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?

> 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.

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

#192

Post by pxc » Fri, Mar 15, 2024, 6:11 PM UTC

OJFord wrote: post #171

tomberek wrote: post #51

Earlier quoted context omitted.

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.

Isn't there nix shell for that, and nix-direnv to activate automatically?

In some environments, not-building stuff you might want to do could include launching/supervising long-lived processes (services), connecting networked filesystems and mounting them somewhere appropriate, firing up VMs, etc. Some of this you can definitely do with direnv but if you want reproducibility with those aspects of your environment, building it on top of Nix seems like a more natural fit to me.

There are other tools that compete in this space right now (devenv.sh, flake.parts, devbox), and for simple use cases a basic direnv integration might be just fine. But the role Flox is aiming for here seems pretty clear imo.

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

#193

Post by pxc » Fri, Mar 15, 2024, 6:17 PM UTC

OJFord wrote: post #99

zamalek wrote: post #85

Earlier quoted context omitted.

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 dire…

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,…

> Is it that the latter is for actually building/running the debug build locally

Yes, I think. `nix-develop` sets up the environment variables and functions required by the build, both on the Nix side and on the side of the application you're trying to build. So you get all the variables that will be in play in the Nix build sandbox, from the bash functions for each phase of the build and Nix-specific env vars to env vars for things like your CMAKE flags or your PYTHONPATH. `nix develop` lets you interactively explore the build exactly the way Nix will do it, so you can test each piece and maybe even try some manual build steps that aren't yet in place for a build that's not entirely working.

`nix shell` is a simpler 'hey, equip my $PATH with these programs, thanks'

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

#194

Post by pxc » Fri, Mar 15, 2024, 6:39 PM UTC

stephenr wrote: post #34

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 developer…

> 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.

The kind of default/minimum reproducibility for most Nix-based deployments is basically a stronger version of this. It's like 'Debian 12 on AMD64 with all the exact versions and non-arch-specific build flags of all packages exactly pinned is very similar to Debian 12 on ARM64 with all package versions and non-arch-specific build flags pinned to the exact same thing'.

> 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).

This is worth digging into.

> there are differences either in features, extensions

Nix will guarantee for you that you always get the exact same features and extensions unless it's truly the case that a feature is just not available on some platforms. So it takes care of differences that come from different operating systems and distros using different ./configure flags and so on.

> or in system level dependencies (i.e. a database server, cache server, etc)

Flox and competitors like it all support local process supervision/service management as well as just adding packages to an environment, so you pin down the versions and configuration options of your DB server and cache server in the environment specification as well.

> Sure, some things work the same or close-enough to the same

For things that are genuinely different (e.g., Nix itself has different sandboxing features and support on Linux because those operating systems' respective kernels also differ in their capabilities), you are still going to want to virtualize. If your production environment is NixOS, there are some pretty nice tools available for this. Otherwise you might want to do your final testing via something like Vagrant or Tart or some custom Nix-based tooling.

But if Docker-in-a-VM is good enough reproducibility for your stack, Nix will probably be a little bit better.

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

#195

Post by mkenigs » Fri, Mar 15, 2024, 8:34 PM UTC

pxc wrote: post #189

mkenigs wrote: post #186

Earlier quoted context omitted.

Hey there! Looks like you may have missed the Nix/Generic and Nix/NixOS tabs at 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…

> Hey there! Looks like you may have missed the Nix/Generic and Nix/NixOS tabs at 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!…

Yes I have worked on it and would love to help if you want to poke around! If you have more questions I can answer on our Slack https://go.flox.dev/slack. It's not completely straightforward how it all works

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

#196

Post by zero0529 » Fri, Mar 15, 2024, 9:41 PM UTC

Is this similar to Devbox by jetpack.io ?

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

#197

Post by Yanael » Fri, Mar 15, 2024, 10:02 PM UTC

ronef wrote: post #150

Yanael wrote: post #62

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…

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 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…

[dead]

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

#198

Post by takeda » Sat, Mar 16, 2024, 4:40 AM UTC

grhmc wrote: post #153

takeda wrote: post #130

Earlier quoted context omitted.

I believe so, it seems like almost all (or all?) solutions listed here: 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 ht…

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 i…

Ah, apologies for getting things wrong. Thanks for explaining it and making it clearer. I just saw the hostility in that thread and that's how I interpreted it.

BTW: I have nothing to do with Flox, I'm just ordinary Nix user who actually likes flakes and also wishes it would get removed from the experimental flag. At this point I agree there's no going back. If flake was removed tomorrow there would be a huge uproar and countless of setups broken. The ship already has sailed and continuing on keeping it behind experimental only undermines what "experimental" supposed to mean.

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

#199

Post by OJFord » Sat, Mar 16, 2024, 1:55 PM UTC

pxc wrote: post #190

OJFord wrote: post #172

Earlier quoted context omitted.

Nix comes with confusion built in though, in the official getting started guide flakes are described as controversial, their history explained, criticisms described, only to ultimately say you have to decide for yourself. Imagine if the Arch or Ubuntu installer halted, told you neutrally / BBC style criticism-focussed even about systemd, and then asked you how to proceed: systemd or sysvinit?

I both love this and totally understand why it can be overwhelming for new users. (I had no idea this was a thing because I've been using (and loving) the flakes-centric DetSys installer for so long now.) It reminds me of how in legal contexts, dissenting views are also part of the record (and can be cited in future cases sometimes), or how in the context of traditional commentaries on certain religions (Islam and Ju…

I guess, but the huge ambiguity of it to me, that I think should be resolved, is is it the future of the project? However controversial it was and respectful it is to give me the choice, my choice is that I want to do what's going to be best supported by the first party, what does upstream expect me to do, especially as a newcomer just trying it out.

(Again, rather. When I first tried it out flakes didn't exist. And actually that makes it even more confusing because the nix profile, nix env stuff I dimly recall is apparently deep plumbing nobody's really expected to use directly any more.)

Maybe the answer is no flakes, because it's disabled by default after all. But then it really does seem like everybody uses flakes now.

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

#200

Post by OJFord » Sat, Mar 16, 2024, 1:58 PM UTC

aidenn0 wrote: post #188

OJFord wrote: post #168

Earlier quoted context omitted.

Can't you just pin pkgs to particular commit, so everything will have the version it did as of that commit?

Right, but traditional nix doesn't make that easy (which is why niv and flakes exist).

I suppose you're just saying it's easier than this with flakes, but this isn't a flake is it? (Honestly so confused about it all, looking at trying out nix again after toying with it briefly years ago.)

https://nix.dev/guides/recipes/sharing-dependencies#complete...