Why we have to keep separation on env and shell(develop)?

I stumbled across this problem and it seems to be specific to nix - Reddit - Dive into anything

Unless I code in nix-shell, then CC won’t be set and running gem install in activated environment and in flox develop are providing different results.

This generally means that flox envs/nix-env are not usable unless you start nix-shell / flox develop that triggers the hooks.

Is that something that Flox will also obey or change completelly so it is easier for developer to understand?

Currently Flox has a lot of syntastic sugar but obeys the laws of Nix. Should the hooks be also done on env activation ?

This is a good question and it’s something we’ve talked about internally recently.

I’ll admit that I don’t 100% follow the Reddit thread you posted, maybe there’s some domain specific Ruby knowledge that I’m missing; but I think I understand the gist of you question. For clarity I’ll rephrase it to check my understanding if you don’t mind:

What is the relationship/difference between flox activate and flox develop as it relates to setup-hooks in Nixpkgs’?
Are there plans to integrate setup-hooks or some similar behavior, such as an advanced “per-package” activation hook, into flox activate?

I’ve started a discussion with our engineers to see if they have any flox activate roadmap info to share, but a few things I can clear up right away are:

  1. flox activate behaves similarly to nix profile install or nix shell insofar as it is not sensitive to setup-hooks. In contrast to nix profile install and nix shell, flox activate does have a slightly more advanced activation hook for each package, but the basics of appending PATH and similar variables hold true.
  2. flox develop and flox shell are literally invoking nix develop and nix shell respectively, and are simply wrappers over the nix CLI which allow catalogs to be integrated “cleanly” into that CLI.

If you could confirm my understanding of the question that would be appreciated, and I’ll keep you in the loop as the discussion with our engineers unfolds.

Thanks for the question!

In my case I had an assumption that if I install gcc and ruby I can do gem install io-console and Ruby will use installed gcc to compile the gem dependencies. Nix generally does not like stuff touching each other but in this specific case “CC” definitions are sed-ed in Ruby internals to use environment variable “CC” and nix-shell hook for stdenv does set it.

In ideal world gem install io-console would be banned because Nix-env should only use nix packages. But in this case, this package does not exist so I had no choice.

The question is though - how much Nix will be in Flox? Will using Flox mean that I have to forget about current path and choose the new one? Most tools I use extend the experience and make it easier, Nix does offer reproducibility but demands great effort. Normal tools won’t work (like pip) unless specifically extended.

So to summary - you are right. If flox activate would behave more like flox/nix shell then this mapping would be defined and I would get experience like I expected.

The question is though - how much Nix will be in Flox? Will using Flox mean that I have to forget about current path and choose the new one? Most tools I use extend the experience and make it easier, Nix does offer reproducibility but demands great effort. Normal tools won’t work (like pip) unless specifically extended.

While Nix is installed with flox and flox depends on Nix, our end goal is that one can use flox and thereby gain all the benefits / powers of Nix (and more :nerd_face:), but not be required to learn Nix. We won’t prevent people from using Nix via flox but the intention is that it won’t be required. We aren’t there yet but that is where we are aiming to be and user feedback is an important part of helping us reach that goal. :heart: