[yeck]

Nix package manager's `nix-shell` is something I wish more people knew about. Nix is gaining some popularity, but people often think of using it has to be a really big commitment, like changing your Linux distro to NixOS or replacing your dotfiles with a Nix-based one (using the Nix package manager).

What I wish more people knew was that you don't need to do those things to get value from Nix. Create project specific dev shells that install the packages (at the correct versions) to work with that project can almost replace 90% of the docs for getting setup to work on a project.

[aliasxneo]

Have you tried compiling software with a nix shell? It gets linked to the Nix store. Needless to say it was a frustrating revelation.

[whacked_new]

The missing link for me is nix-copy-closure, which I learned about from a post by mitchellh: https://mitchellh.com/writing/nix-with-dockerfiles

conceptually a game changer for me. In practice it's far from a silver bullet (because every language prefers its own package management so you still have to manage those), but when it works it's quite magical.

[n8henrie]

You can patchelf to link to the host system libraries instead, or some projects can statically compile (inc musl) with less drama than usual, since your cross compilation toolchain can be part of your nix-shell.

[maxmcd]

Isn't this what you want? You are reliably linking to the specific dynamic libraries you are compiling against.

Or was the issue that you expected them to be portable? Or use commonly known dynamic library locations?

[ParetoOptimal]

Sometimes it matters, many times not.

For example I tried to run pip install yesterday on MemGPT on Nix.

It failed with a C++ error because they use miniconda.

I just created a nix shell with python, pip, etc and ran the pip install command.

Things work fine.

[pricci]

Although I haven't really used it, jetpack.io's Devbox [0] is an abstraction over Nix for the usage you describe.

[0] https://www.jetpack.io/devbox

[yeck]

I've played around with it a little bit, but not enough to make any judgements on it. Something like devbox could be the sort of thing to make nix-shell accessible enough to see wider adoption.

[eternityforest]

Snap also has a way to open a shell inside the context of a snap package

[corethree]

It's good for a c or c++ project where libraries are very environment specific. But most modern languages have their own package/environment managers which makes Nix redundant.

[gaganyaan]

Not really. I introduced it to our Python projects at work and it's been great. Partially because of poetry2nix, and partially because it makes it easy to include other stuff like a specific version of Redis for testing purposes. Everybody gets the exact same dev environment, reducing a ton of "works on my machine".

[tripdout]

Most language package/environment managers do not come close to giving you the guarantees that Nix does.

[otabdeveloper4]

Two problems:

a) Unless you literally write everything in one language, you will have to deal with learning, supporting and fixing bugs in N different package/environment managers instead of just one.

b) If you have a project that uses several languages (say, a Python webapp with C++ extensions and frontend templates in Typescript), then Nix is the only solution that will integrate this mess under one umbrella.

[jcelerier]

I had to use it for a c++ project and it was one of the biggest waste of time and frustrating moments of my computing career, there were constant breakages due to glibc mismatches, Nvidia drivers and whatnot, and getting an host IDE to have semantic understanding of the paths , etc... necessary for normal completions and stuff was nigh impossible.

[anon291]

No way. Language specific managers are terrible at managing external dependencies. Trying to get python packages to link to system libraries is terrible. Nix makes it infinitely better.