Live data from Hacker News

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

github.com

181–190 of 201 posts

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

#181
post #173

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

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

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.

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

#182
post #165

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?

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

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

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

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

#184
post #31

Earlier quoted context omitted.

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…

I am no expert, but yes, it's flakes for my projects. It keeps the build time tooling separate (eg Go compiler, node version,etc) from the main system (so I could for example have different versions for different projects). It also makes it easier for others that might (one day) contribute to my projects to start developing (assuming they're using nix) with the same tooling and versions that I am using. aiui, nix she…

nix DASH shell (`nix-shell`) is a pre-flakes command. nix SPACE shell (`nix shell`) is a flakes-based command.

Flakification split two common use cases of nix-shell into two separate commands, `nix shell` and `nix develop`.

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

#185

Earlier quoted context omitted.

I don’t know anyone who is recommending against flakes these days. The “experimental” label is more about the API stability than completeness, bugginess, or anything else. There are certain scenarios where the performance can be problematic, but there are workarounds and permanent solutions are being worked on. Nevertheless, using flakes extensively at home and work.

>I don’t know anyone who is recommending against flakes these days. The “experimental” label is more about the API stability than completeness, bugginess, or anything else. "Experimental" traditionally means "if you use it and it breaks, then that's your fault". This is because if did break, the entire internet would dogpile on any complainers with "IT WAS LABELLED EXPERIMENTAL WHAT WERE YOU EXPECTING." It's the same…

Here's the closest thing to an 'unwarning' that can exist, which is a tl;dr of the history:

The experimental label is a historical compromise because flakes, which was conceived by the original author of Nix (who is still a maintainer), was a major change merged to master without going through the whole Nix community RFC process (which was then in its infancy).

So it was added, but tucked away behind an 'experimental' designation and enablement flag. This proved controversial at the time and perhaps still is among old timers, but in the interim flakes have become enormously popular with new users (probably most people who picked up Nix in the past 3 years or so).

Third-party adoption of flakes has by now reached the point that the vast majority of big tools in the Nix ecosystem support it well. Some interfaces are still officially unstable but serious breakage is pretty rare. The flakes implementation in the codebase is very usable but still incomplete and still a bit buggy, and straightening out the kinks in the implementation as well as stabilizing the interfaces (both for Nix code and the CLI) is careful, patient work under way right now.

Hence the common recommendation to just use 'em unless you have deep Nix knowledge and a specific reason not to.

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

#186
post #183

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

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 a workaround? We error for any shell other than bash or zsh somewhere around 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!

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

#188
post #168
post #92

Earlier quoted context omitted.

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…

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

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

#189
post #183

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

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

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

#190
post #172

Earlier quoted context omitted.

IMO it's a bit more like asking the python community to standardize all the tools listed in this stackoverflow question, which they only sort of succeeded in. "What is the difference between venv, pyvenv, pyenv, virtualenv, virtualenvwrapper, pipenv, etc?" https://stackoverflow.com/questions/41573587/what-is-the-dif...

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 Judaism come to mind, but I'm sure there are others), the tradition is not just to record and teach a 'winning' side, but to record and teach the entire debate.

Can it be overwhelming? Yes. Is it the kind of thing engineers are looking for? Often, no. But it is a deeply respectful and thoughtful way to treat people and topics imo.

Post reply on HN