Sure - you're Nixing wrong. Not to worry, it actually takes ages to figure out how to Nix right - there's not enough documentation on the matter.

The correct way to get almost anything installed is to write a Nix package, and install that. This is actually remarkably easy in comparison to other package managers - you write the package definition in a single file, normally just having to set the source code location and list its dependencies, and you can make it available to install with nix-env by adding it to a packageOverrides declaration in ~/.config/nixpkgs/config.nix.

The "stdenv" build system that nixpkgs uses will automatically install anything that can be configured via "./configure && make && make install" - cmake is supported just by listing that as a build dependency. Stuff written in scripting languages is more fiddly, but the nixpkgs documentation usually has examples. The downside is that a significant amount of the time, libraries written in scripting languages aren't packaged either, and you wind up packaging half a dozen libraries just to get some tool working. The <X>2nix tools can be useful in these cases to generate a package definition.

Thank you for the awesome reply (and everyone else). This is precisely the issue I have though:

> The downside is that a significant amount of the time, libraries written in scripting languages aren't packaged either, and you wind up packaging half a dozen libraries just to get some tool working.

I've gone down this path a few times and days later when I still don't have the original thing I wanted working installed, then I sort of give up. I realize there are many benefits to Nix and I really enjoy them but I've switched to using Arch for practical reasons. I really, really miss the declarative reproducible style though.

What I wind up doing while developing is just creating a nix-shell with my native dependencies, and using pip/cargo/whatever inside that. It's not the "proper" way of doing things - you wouldn't want to install a tool long-term that way - but it's useful for one-off things or while you're playing around.

I've used npm2nix and cargo2nix a couple of times with success - they generate package sets from the relevant sources.

>you wouldn't want to install a tool long-term that way

I'm curious why not.

Aren't pip/cargo/whatever suitable for long-term use?

Consequently, couldn't nix's upgrading routines be modified to call out to pip/cargo/whatever to upgrade things best upgraded by pip/cargo/whatever?

I guess what I want to know is whether the architecture or the philosophy of nix interferes with nix's being modified in the way I just described. (Maybe it is just that nobody's gotten around to doing the implementation work.)

> Consequently, couldn't nix's upgrading routines be modified to call out to pip/cargo/whatever to upgrade things best upgraded by pip/cargo/whatever?

No. pip/cargo/etc are nondeterministic. Nix packages should not be. Where they are, things often break in bizarre ways.

In order to access the Internet, a Nix package must declare the hash of its output - given that pip can produce different output from run to run (it contains a constraint solver which depends on the versions available in the external package repository) this is impossible.

Have you tried using something like `home-manager` (https://github.com/rycee/home-manager)? It gives you declarative package and configuration management with Nix on non-NixOS. It might be a nice compromise until NixOS/Nixpkgs is mature enough to meet your needs more completely. Or maybe you'll never switch, if you really like the convenience of being able to easily grab a trendy package from AUR or whatever. But either way, there's a lot of declarative Nix-y goodness you can get on Arch Linux! :-D

There's a similar tool for macOS called `nix-darwin`, as well: https://github.com/LnL7/nix-darwin

You shouldn't be using /bin/bash anyway. The proper she-bang is '#!/usr/bin/env bash', which works on nix. The location of bash in /bin/ is actually not standard at all, despite some linux distributions doing that. In particular, the BSDs also do not have bash in /bin. This is why using '/usr/bin/env bash' is more portable

> /usr/bin/env

That won't work everywhere either as the location of 'env' is not a fixed standard either. Eg. In some *nix's its at /bin/env.

What modern/surviving Unix-likes don't have even a symlink in `/usr/bin/env`?

I'm not 100% sure on all of these, but every one of the dozens of Linux distros I've used has `/usr/bin/env`. macOS has it, and it looks like FreeBSD does, too, and so does NetBSD.

Who are the oddballs? Does it include any of the free Unices?

(I'm not trying to be shitty; I'd really like to know. I spent some time Googling about conventions for the `env` command, and examples of incompatible systems. The only ones I found were two old, proprietary Unices. I got tired of searching and was hoping someone who knows a few examples offhand could help me out.)

I've always mechanically written '#!/bin/bash' as my shebang for bash script, while I normally use '#!/usr/bin/env python' for python scripts. In retrospect, that sounds obviously incoherent.

I would like to know if there is some common practice/standard around using '/usr/bin/env' in shebangs.

Could you please elaborate more?

But is `/usr/bin/env` standard?

Incidentally, macOS, whose CLI is derived from BSD, does in fact have /bin/bash.

Conversely, Python's PEP394 explicitly discourages `/usr/bin/env python`, so there's that. (I know why the PEP says so, just pointing out that it differs from Nix style)

The PEP doesn't even mention /usr/bin/env. Look for yourself: https://www.python.org/dev/peps/pep-0394/

Please don't down-vote criticism. This is a real feedback which I am sure applies to a lot of new-comers.

There is a `/bin/sh` and `/usr/bin/env` provided - so you can use `/usr/bin/env bash`.

There is also this function which may be necessary for certain software: https://nixos.org/nixpkgs/manual/#sec-fhs-environments

You can compile some software manually in place using, for example, `nix-shell -p libssh2 -p zlib` without having to write a derivation. However, without writing a derivation, it may cease to function after a garbage collection or an upgrade.

Writing a derivation isn't too bad, here's one for one of my repos: https://github.com/jbboehr/handlebars.c/blob/master/derivati...