Hacker News Reader

Comment by mrd3v0 | Hacker News Reader

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.

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.

I think you're discussing direnv, not devenv -- which appears to be a direct alternative to Flox

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

> 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

yes, thanks!

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

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.

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

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

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 shell was the non-flake way of doing things and nix develop is for flakes (this is probably a gross over simplification!)

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

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.

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.

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.

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.

Your analogy would've made sense if Nix had a few dozen implementations to choose from, all being similar in scope and none being definitively better. These are tools that build upon Nix. The whole point of a language is to have tools that build upon it. It's nothing line the Python -env situation where the sole purpose is to mitigate a design flaw in packaging.

Well, I wonder about all language communities why they don’t coordinate efforts indeed. I see monthly arrivals of new ‘js runtimes’ and package managers as well. And that eco system is a lot larger than nix. If these talented people would band together, wouldn’t we get a better endresult as a whole? If it’s commercial products then that doesn’t work, but this is all nice open source under good licenses, so outside ego, what’s the benefit of 50000 things that do the same thing except 499XX*n hours of life wasted?

Reply on news.ycombinator.com