6 ms·

What is the benefit of using Flox over plain nix-shell or nix develop?

by ivanjermakov 3y ago

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).
        srid 3y ago
        > 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 https://community.flake.parts/services-flake
        vhodges 3y ago
        yes, thanks!
        OJFord 3y ago
        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#declarative-reproducible-envs https://nix.dev/tutorials/first-steps/declarative-shell#decl...
        zamalek 3y ago
        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 3y ago
        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 3y ago
      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 3y ago
      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.
      - EE84M3i 3y ago
        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-difference-between-venv-pyvenv-pyenv-virtualenv-virtualenvwrappe https://stackoverflow.com/questions/41573587/what-is-the-dif...
        OJFord 3y ago
        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?
        pxc 3y ago
        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.
mkenigs 3y ago
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 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 3y ago
  You know you can just write `nix develop -c zsh` or `nix develop -c fish` or whatever, right?
  - tomberek 3y ago
    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 3y ago
      Interesting, thanks.
    - OJFord 3y ago
shubber 3y ago
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 3y ago
  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 3y ago
  Does a python developer NEED to know how C works to write automation scripts that work reasonably well? This logic is silly.

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).
      - srid 3y ago
        > 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 https://community.flake.parts/services-flake
        vhodges 3y ago
        yes, thanks!
      - OJFord 3y ago
        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#declarative-reproducible-envs https://nix.dev/tutorials/first-steps/declarative-shell#decl...
        zamalek 3y ago
        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 3y ago
        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 3y ago
    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 3y ago
    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.
    - EE84M3i 3y ago
      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-difference-between-venv-pyvenv-pyenv-virtualenv-virtualenvwrappe https://stackoverflow.com/questions/41573587/what-is-the-dif...
      - OJFord 3y ago
        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?
        pxc 3y ago
        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.

mkenigs 3y ago

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 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 3y ago
You know you can just write `nix develop -c zsh` or `nix develop -c fish` or whatever, right?
- tomberek 3y ago
  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 3y ago
    Interesting, thanks.
  - OJFord 3y ago

shubber 3y ago

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 3y ago
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 3y ago
Does a python developer NEED to know how C works to write automation scripts that work reasonably well? This logic is silly.