nix-shell(1)

📦
version 2.35.3 · 12 versions
, in fedora 44

nix-shell(1) — General Commands Manual ✨

🎀 NAME 🎀

nix-shell — start an interactive shell based on a Nix expression. 💅

🌈 SYNOPSIS 🌈

nix-shell [--arg name value] [--argstr name value] [{--attr | -A}
       attrPath] [--command cmd] [--run cmd] [--exclude regexp] [--pure]
       [--keep name] {{--packages | -p} {packages | expressions} … | [path]}

🦋 DISAMBIGUATION 🦋

Okay bestie, listen: this man page describes the command nix-shell, which is distinct from nix shell. For documentation on the latter, run nix shell --help or see man nix3-env-shell. 👑

✨ DESCRIPTION ✨

The command nix-shell will build the dependencies of the specified derivation, but not the derivation itself. It will then start an interactive shell in which all environment variables defined by the derivation path have been set to their corresponding values, and the script $stdenv/setup has been sourced. This is useful for reproducing the environment of a derivation for development. 🛠️💖

If path is not given, nix-shell defaults to shell.nix if it exists, and default.nix otherwise. 🗂️

If path starts with http:// or https://, it is interpreted as the URL of a tarball that will be downloaded and unpacked to a temporary location. The tarball must include a single top-level directory containing at least a file named default.nix. 🌐📦

If the derivation defines the variable shellHook, it will be run after $stdenv/setup has been sourced. Since this hook is not executed by regular Nix builds, it allows you to perform initialisation specific to nix-shell. For example, the derivation attribute

       shellHook =
         ''
           echo "Hello shell"
           export SOME_API_TOKEN="$(cat ~/.config/some-app/api-token)"
         '';

will cause nix-shell to print Hello shell and set the SOME_API_TOKEN environment variable to a user-configured value. 🐚💜

💅 OPTIONS 💅

All options not listed here are passed to nix-store --realise, except for --arg and --attr / -A which are passed to nix-instantiate.

  • --command cmd — In the environment of the derivation, run the shell command cmd. This command is executed in an interactive shell. (Use --run to use a non-interactive shell instead.) However, a call to exit is implicitly added to the command, so the shell will exit after running the command. To prevent this, add return at the end; e.g. --command "echo Hello; return" will print Hello and then drop you into the interactive shell. This can be useful for doing any additional initialisation. ✨
  • --run cmd — Like --command, but executes the command in a non-interactive shell. This means (among other things) that if you hit Ctrl+C while the command is running, the shell exits. 😭
  • --exclude regexp — Do not build any dependencies whose store path matches the regular expression regexp. This option may be specified multiple times. 🚫
  • --pure — If this flag is specified, the environment is almost entirely cleared before the interactive shell is started, so you get an environment that more closely corresponds to the “real” Nix build. A few variables, in particular HOME, USER and DISPLAY, are retained. Note that the shell used to run commands is obtained from NIX_BUILD_SHELL / <nixpkgs> from NIX_PATH, and therefore not affected by --pure. 🧼
  • --packages / -p packages… — Set up an environment in which the specified packages are present. The command line arguments are interpreted as attribute names inside the Nix Packages collection. Thus, nix-shell --packages libjpeg openjdk will start a shell in which the packages denoted by the attribute names libjpeg and openjdk are present. 📦👑
  • -i interpreter — The chained script interpreter to be invoked by nix-shell. Only applicable in #!-scripts (described below). 🧚
  • --keep name — When a --pure shell is started, keep the listed environment variables. 💖

🫶 COMMON OPTIONS 🫶

ok bestie, listen — literally almost every Nix command talks in this same little dialect, so once you learn these you're basically fluent. Most Nix commands accept the following command-line options:

  • --help — Prints out a summary of the command syntax and exits. (Your "wait what do I even type" bestie 💅)
  • --version — Prints out the Nix version number on standard output and exits.
  • --verbose / -v — Turns UP the level of verbosity of diagnostic messages printed on standard error. Here's the tea: for each Nix operation, whatever gets printed on standard output is well-defined; any diagnostic info goes to standard error, and never to standard output. No cap.

This option can be specified repeatedly, and rn these are the verbosity levels that exist:

  • 0 "Errors only" — Only print messages explaining why the Nix invocation failed. 💀
  • 1 "Informational" — Print useful messages about what Nix is doing. This is the default.
  • 2 "Talkative" — Print more informational messages. She's chatty!
  • 3 "Chatty" — Print even more informational messages.
  • 4 "Debug" — Print debug information.
  • 5 "Vomit" — Print vast amounts of debug information. Yes it's literally called that. Iconic, honestly. 🤢
  • --quiet — Turns DOWN the level of verbosity of diagnostic messages printed on standard error. It's the inverse option to -v / --verbose. This option may be specified repeatedly. See the previous verbosity levels list (scroll up bestie ⬆️).
  • --log-format format — This option can be used to change the output of the log format, with format being one of:
    • raw — This is the raw format, as outputted by nix-build.
    • internal-json — Outputs the logs in a structured manner.
⚠️ Warning — While the schema itself is relatively stable, the format of the error-messages (namely of the msg-field) can change between releases. So like, don't hard-depend on the exact wording, got it? 🫶
  • bar — Only display a progress bar during the builds. So satisfying to watch ngl.
  • bar-with-logs — Display the raw logs, with the progress bar at the bottom. Best of both worlds, we love to see it.
  • --no-build-output / -Q — By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. This option suppresses that behaviour. Lowkey important detail: the builder's standard output and error are always written to a log file in prefix/nix/var/log/nix, no matter what.
  • --max-jobs / -j number — Sets the maximum number of build jobs that Nix will perform in parallel to the specified number. Specify auto to use the number of CPUs in the system. The default is specified by the max-jobs configuration setting, which itself defaults to 1. A higher value is useful on SMP systems or to exploit I/O latency. ✨

Setting it to 0 disallows building on the local machine, which is exactly what you want when you only want builds happening on remote builders. main character scheduling energy.

  • --cores — Sets the value of the NIX_BUILD_CORES environment variable in the invocation of builders. Builders can use this variable at their discretion to control the maximum amount of parallelism. For instance, in Nixpkgs, if the derivation attribute enableParallelBuilding is set to true, the builder passes the -jN flag to GNU Make. It defaults to the value of the cores configuration setting, if set, or 1 otherwise. The value 0 means that the builder should use all available CPU cores in the system. Go off, machine. 🔥
  • --max-silent-time — Sets the maximum number of seconds that a builder can go without producing any data on standard output or standard error. The default is specified by the max-silent-time configuration setting. 0 means no time-out. Silence is NOT golden here bestie, we're watching. 👀
  • --timeout — Sets the maximum number of seconds that a builder can run. The default is specified by the timeout configuration setting. 0 means no timeout. (hehe, "no timeout")
  • --keep-going / -k — Keep going in case of failed builds, to the greatest extent possible. That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds). So like... it's the "don't panic, keep the group chat going" flag. 💅
  • --keep-failed / -K — Specifies that in case of a build failure, the temporary directory (usually in /tmp) in which the build takes place should not be deleted. The path of the build directory is printed as an informational message. Perfect for when you wanna go poke at the crime scene 🔍.
  • --fallback — Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.

The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. 🦋 This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources). Like, a lil network blip should not summon a 4-hour compile, fr fr.

  • --readonly-mode — When this option is used, no attempt is made to open the Nix database. Most Nix operations do need database access, so those operations will fail. Look but don't touch energy. 🙈
  • --arg name value — This option is accepted by nix-env, nix-instantiate, nix-shell and nix-build. When evaluating Nix expressions, the expression evaluator will automatically try to call functions that it encounters. It can automatically call functions for which every argument has a default value (e.g., { argName ? defaultValue }: ...).

With --arg, you can also call functions that have arguments without a default value (or override a default value). That is, if the evaluator encounters a function with an argument named name, it will call it with value value.

For instance, the top-level default.nix in Nixpkgs is actually a function:

{ # The system (e.g., `i686-linux') for which to build the packages.
system ? builtins.currentSystem
...
}: ...

So if you call this Nix expression (e.g., when you do nix-env --install --attr pkgname), the function will be called automatically using the value builtins.currentSystem for the system argument. You can override this using --arg, e.g., nix-env --install --attr pkgname --arg system \"i686-freebsd\". (Note that since the argument is a Nix string literal, you have to escape the quotes.) Very "actually you can control the universe" of it all.

  • --arg-from-file name path — Pass the contents of file path as the argument name to Nix functions. Slurp it straight from disk, no middleman. 💾
  • --arg-from-stdin name — Pass the contents of stdin as the argument name to Nix functions. Piping it in is such a mood.
  • --argstr name value — This option is like --arg, only the value is not a Nix expression but a string. So instead of --arg system \"i686-linux\" (the outer quotes are to keep the shell happy) you can say --argstr system i686-linux. Way less escaping drama. 🎀
  • --attr / -A attrPath — Select an attribute from the top-level Nix expression being evaluated. (nix-env, nix-instantiate, nix-build and nix-shell only.) The attribute path attrPath is a sequence of attribute names separated by dots. For instance, given a top-level Nix expression e, the attribute path xorg.xorgserver would cause the expression e.xorg.xorgserver to be used. See nix-env --install for some concrete examples.

In addition to attribute names, you can also specify array indices. For instance, the attribute path foo.3.bar selects the bar attribute of the fourth element of the array in the foo attribute of the top-level expression. (Yes bestie, 3 = the fourth element. Zero-indexed, we don't make the rules. 💀)

  • --eval-store store-url — The URL to the Nix store to use for evaluation, i.e. where to store derivations (.drv files) and inputs referenced by them.
  • --expr / -E — Interpret the command line arguments as a list of Nix expressions to be parsed and evaluated, rather than as a list of file names of Nix expressions. (nix-instantiate, nix-build and nix-shell only.)

For nix-shell, this option is commonly used to give you a shell in which you can build the packages returned by the expression. If you want to get a shell which contain the built packages ready for use, give your expression to the nix-shell --packages convenience flag instead. Choose your fighter. 🥊

  • -I / --include path — Add an entry to the list of search paths used to resolve lookup paths. This option may be given multiple times.

Paths added through -I take precedence over the nix-path configuration setting and the NIX_PATH environment variable. Precedence queen. 👑

  • --impure — Allow access to mutable paths and repositories. Chaos mode: enabled. 🌈
  • --option name value — Set the Nix configuration option name to value. This overrides settings in the Nix configuration file (see nix.conf5).
  • --repair — Fix corrupted or missing store paths by redownloading or rebuilding them. Heads up though: this is slow because it requires computing a cryptographic hash of the contents of every path in the closure of the build. Also note the warning under nix-store --repair-path. So like, grab a snack first. 🍓
📝 Note — See man nix.conf for overriding configuration settings with command line flags.

🌸 ENVIRONMENT VARIABLES 🌸

  • NIX_BUILD_SHELL — Shell used to start the interactive environment. Defaults to the bash from bashInteractive found in <nixpkgs>, falling back to the bash found in PATH if not found. She's resourceful like that. 💜
📝 Note — The shell obtained using this method may not necessarily be the same as any shells requested in path.
**Example — Despite --pure, this invocation will not result in a fully reproducible shell environment:
#!/usr/bin/env -S nix-shell --pure
let
  pkgs = import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/854fdc68881791812eddd33b2fed94b954979a8e.tar.gz") {};
in
pkgs.mkShell {
  buildInputs = pkgs.bashInteractive;
}

💖 COMMON ENVIRONMENT VARIABLES 💖

Okay bestie, listen up — basically most Nix commands out here read these environment variables, so you wanna know them. No cap. 🫶

🔧 Configuration environment variables

These ones lowkey control how Nix loads up its configuration. Go read the configuration file documentation if you want the full tea.

  • NIX_CONF_DIR — overrides the system configuration directory. It's giving "I run this now."
  • NIX_USER_CONF_FILES — overrides where the user configuration files live. Changing the vibe of your config locations, fr.
  • NIX_CONFIG — hands you configuration settings inline. Right there in the variable, no file needed. Iconic.

🏬 Store setting environment variables

  • NIX_IGNORE_SYMLINK_STORE — so normally the Nix store directory (typically /nix/store) is not allowed to contain any symlink components. Why? To prevent "impure" builds, bestie. Here's the lore: builders sometimes "canonicalise" paths by resolving all the symlink components. Which means builds on different machines (where /nix/store resolves to different locations) could yield different results 😭. Usually that's not a problem — except when builds get deployed to machines where /nix/store resolves differently. If you're 100% sure you're not gonna do that, you can set NIX_IGNORE_SYMLINK_STORE to 1.
Heads up: if you're symlinking the Nix store so you can park it on a different file system than the root file system, on Linux you're way better off using bind mount points, like:
$ mkdir /nix
$ mount -o bind /mnt/otherdisk/nix /nix

Go consult the mount 8 manual page for the details, k? ✨

  • NIX_STORE_DIR — overrides the location of the Nix store. On Unix the default is /nix/store, which is set at compile time by the libstore:store-dir build option. On Windows there's no compile-time setting at all — the default is %PROGRAMDATA%\nix\store, figured out at runtime using the %PROGRAMDATA% Known Folder.

Also go peep the Store Types chapter — each store has a store setting that links back to this as its default. 🦋

  • NIX_LOG_DIR — overrides the location of the Nix log directory. On Unix the default is /nix/var/log/nix, set at compile time by the log-dir build option. On Windows, again, no compile-time setting; the default is %PROGRAMDATA%\nix\log, determined at runtime using the %PROGRAMDATA% Known Folder.

The Local Store, Local Daemon Store, and Experimental SSH Store with filesystem mounted all have per-store settings that override this.

  • NIX_STATE_DIR — overrides the location of the Nix state directory. On Unix the default is ${localstatedir}/nix, where localstatedir is a compile-time build option that defaults to /nix/var. On Windows, no compile-time setting; the default is %PROGRAMDATA%\nix\state, worked out at runtime using the %PROGRAMDATA% Known Folder.

Same deal — Local Store, Local Daemon Store, and Experimental SSH Store with filesystem mounted have per-store settings that override this.

  • NIX_DAEMON_SOCKET_PATH — overrides the path to the Unix domain socket used to talk to the Nix daemon. Defaults to daemon-socket/socket inside the state directory (see NIX_STATE_DIR, bestie).

For the deets on how the socket path gets resolved, check the Local Daemon Store documentation. 💅

  • TMPDIR — use this directory to store temporary files. Specifically, this includes temporary build directories, and those can eat up substantial amounts of disk space, so be mindful. Default is /tmp.
  • NIX_REMOTE — overrides the store setting. That's it, that's the whole vibe.

🧠 Nix language evaluator settings

  • NIX_SHOW_STATS — set it to 1 and Nix prints out some evaluation statistics, like the number of values allocated. Numbers go brrr 📊
  • NIX_COUNT_CALLS — set it to 1 and Nix prints how often functions got called during Nix expression evaluation. Super useful for profiling your Nix expressions, ngl.
  • GC_INITIAL_HEAP_SIZE — if Nix was configured to use the Boehm garbage collector, this variable sets the initial size of the heap in bytes. Defaults to 384 MiB. Setting it low reduces memory consumption, but will increase runtime because of garbage collection overhead. Trade-offs, amirite? 😭
  • NIX_PATH — a colon-separated list of search path entries used to resolve lookup paths.

This environment variable overrides the value of the nix-path configuration setting.

You can extend it using the -I option. ✨

Example
$ export NIX_PATH=/home/eelco/Dev:nixos-config=/etc/nixos

And if NIX_PATH is set to an empty string, resolving search paths will always fail. Periodt.

Example
$ NIX_PATH= nix-instantiate --eval '<nixpkgs>'
error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)

🏠 User Directories

Nix supports per-user configuration, state, and cache directories. These environment variables override the locations for those directories:

  • user configuration directory {#user-conf-dir}: NIX_CONFIG_HOME {#env-NIXCONFIGHOME}
  • user state directory: NIX_STATE_HOME {#env-NIXSTATEHOME}
  • user cache directory: NIX_CACHE_HOME {#env-NIXCACHEHOME}

When these aren't set, the defaults depend on the platform, babes:

  • On Unix, the XDG base directories: $XDG_CONFIG_HOME/nix, $XDG_STATE_HOME/nix, $XDG_CACHE_HOME/nix
  • On Windows, the Windows Known Folders: %APPDATA%\nix\config, %LOCALAPPDATA%\nix\state, %LOCALAPPDATA%\nix\cache

For backwards compatibility, legacy Nix commands (think nix-env, nix-channel) use dotfiles in $HOME instead of these directories — unless use-xdg-base-directories is enabled. New Nix commands (experimental) use the proper directories by default. Slay.

When use-xdg-base-directories is enabled, the configuration directory is resolved like this:

  1. $NIX_CONFIG_HOME, if it is defined
  2. Otherwise, the platform default (e.g. $XDG_CONFIG_HOME/nix on Unix)

Same logic for the state and cache directories. 💖

🎀 Miscellaneous environment variables

  • IN_NIX_SHELL — an indicator that tells you whether the current environment was set up by nix-shell. It can have the values pure or impure. Vibe check on your own shell! 🌸

💜 Appendix: OS-specific conventions 💜

Quick note: this info isn't Nix-specific, it's just referenced up above. Okay? Okay.

Unix: XDG Base Directories

The XDG Base Directory Specification defines standard locations for user-specific configuration, state, and cache files on Unix systems. 🐧

The following environment variables are used:

  • XDG_CONFIG_HOME {#env-XDGCONFIGHOME} (default ~/.config)
  • XDG_STATE_HOME {#env-XDGSTATEHOME} (default ~/.local/state)
  • XDG_CACHE_HOME {#env-XDGCACHEHOME} (default ~/.cache)
  • XDG_CONFIG_DIRS {#env-XDGCONFIGDIRS} (default /etc/xdg) — a colon-separated list of additional configuration base directories, searched after XDG_CONFIG_HOME

Windows: Known Folders

On Windows, Known Folders provide standard locations for application data. 🪟

The relevant folders are:

  • %APPDATA% {#env-APPDATA} — per-user roaming application data
  • %LOCALAPPDATA% {#env-LOCALAPPDATA} — per-user local application data
  • %PROGRAMDATA% {#env-PROGRAMDATA} — system-wide application data

✨ EXAMPLES ✨

Bestie, this is where it gets fun. Let's actually do stuff.

Wanna build the dependencies of the package Pan, and start an interactive shell in which to build it? Say less:

$ nix-shell '<nixpkgs>' --attr pan
[nix-shell]$ eval ${unpackPhase:-unpackPhase}
[nix-shell]$ cd $sourceRoot
[nix-shell]$ eval ${patchPhase:-patchPhase}
[nix-shell]$ eval ${configurePhase:-configurePhase}
[nix-shell]$ eval ${buildPhase:-buildPhase}
[nix-shell]$ ./pan/gui/pan

Now, the reason we use the form eval ${configurePhase:-configurePhase} here? It's because those packages that override these phases do so by exporting the overridden values in the environment variable of the same name. So here bash is being told to either evaluate the contents of 'configurePhase', if it exists as a variable — otherwise evaluate the configurePhase function. Sneaky but iconic. 🧚

Wanna clear the environment first, and do some additional automatic initialisation of the interactive shell? Here:

$ nix-shell '<nixpkgs>' --attr pan --pure \
    --command 'export NIX_DEBUG=1; export NIX_CORES=8; return'

Nix expressions can also be given right on the command line using the -E and -p flags. For instance, the following starts a shell containing the packages sqlite and libX11:

$ nix-shell --expr 'with import <nixpkgs> { }; runCommand "dummy" { buildInputs = [ sqlite xorg.libX11 ]; } ""'

A shorter way to do the exact same thing is:

$ nix-shell --packages sqlite xorg.libX11
[nix-shell]$ echo $NIX_LDFLAGS
… -L/nix/store/j1zg5v…-sqlite-3.8.0.2/lib -L/nix/store/0gmcz9…-libX11-1.6.1/lib …

And btw, -p accepts multiple full nix expressions that are valid in the buildInputs = [ ... ] shown above — not just package names. So the following is also totally legal:

$ nix-shell --packages sqlite 'git.override { withManual = false; }'

Obsessed with the flexibility, honestly. 💅

The -p flag looks up Nixpkgs in the Nix search path. You can override it by passing -I or setting NIX_PATH. For example, the following gives you a shell containing the Pan package from a specific revision of Nixpkgs:

$ nix-shell --packages pan -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/8a3eea054838b55aca962c3fbde9c83c102b8bf2.tar.gz

[nix-shell:~]$ pan --version
Pan 0.139

Chef's kiss. 👑

✨ Use as a #!-interpreter ✨

okay bestie this is the iconic part. you can use nix-shell as a script interpreter, which means a script written in literally any language can go get its own dependencies through Nix. princess treatment for scripts. 💅

how? you start the script with these lines:

#! /usr/bin/env nix-shell
#! nix-shell -i real-interpreter --packages packages

where real-interpreter is the "real" script interpreter that nix-shell will invoke after it's grabbed the dependencies and initialised the environment, and packages are the attribute names of the dependencies in Nixpkgs.

the lines starting with #! nix-shell are where you specify nix-shell options (see above — the options section, you remember it, you ate). 🍓

⚠️ not me being the bearer of bad news but you cannot write #! /usr/bin/env nix-shell -i ... because many operating systems only allow one argument in #! lines. one. singular. that's the limit bestie, the OS said no. 💀

for example, here's a Python script that depends on Python and the prettytable package:

#! /usr/bin/env nix-shell
#! nix-shell -i python3 --packages python3 python3Packages.prettytable

import prettytable

# Print a simple table.
t = prettytable.PrettyTable(["N", "N^2"])
for n in range(1, 10): t.add_row([n, n * n])
print(t)

🌸 cute, functional, self-sufficient.

similarly, the following is a Perl script that specifies it requires Perl and the HTML::TokeParser::Simple, LWP and LWP::Protocol::Https packages:

#! /usr/bin/env nix-shell
#! nix-shell -i perl
#! nix-shell --packages perl
#! nix-shell --packages perlPackages.HTMLTokeParserSimple
#! nix-shell --packages perlPackages.LWP
#! nix-shell --packages perlPackages.LWPProtocolHttps

use HTML::TokeParser::Simple;

# Fetch nixos.org and print all hrefs.
my $p = HTML::TokeParser::Simple->new(url => 'https://nixos.org/');

while (my $token = $p->get_tag("a")) {
    my $href = $token->get_attr("href");
    print "$href\n" if $href;
}

look at all those #! nix-shell lines stacking up. the way that they just merge together... it's giving ✨layers✨.

sometimes you need to pass a simple Nix expression to customize a package like Terraform:

#! /usr/bin/env nix-shell
#! nix-shell -i bash --packages 'terraform.withPlugins (plugins: [ plugins.openstack ])'

terraform apply
Note 📌 You must use single or double quotes (', ") when passing a simple Nix expression in a nix-shell shebang.

do not skip the quotes. the quotes are the whole point. no cap. 🙈

finally, using the merging of multiple nix-shell shebangs, the following Haskell script uses a specific branch of Nixpkgs/NixOS (the 20.03 stable branch):

#! /usr/bin/env nix-shell
#! nix-shell -i runghc --packages 'haskellPackages.ghcWithPackages (ps: [ps.download-curl ps.tagsoup])'
#! nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/nixos-20.03.tar.gz

import Network.Curl.Download
import Text.HTML.TagSoup
import Data.Either
import Data.ByteString.Char8 (unpack)

-- Fetch nixos.org and print all hrefs.
main = do
  resp <- openURI "https://nixos.org/"
  let tags = filter (isTagOpenName "a") $ parseTags $ unpack $ fromRight undefined resp
  let tags' = map (fromAttrib "href") tags
  mapM_ putStrLn $ filter (/= "") tags'

if you want to be even more precise, you can specify a specific revision of Nixpkgs:

#! nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/0672315759b3e15e2121365f067c1c8c56bb4722.tar.gz

pin it down. lock it in. main character energy. 👑

the examples above all used -p to get dependencies from Nixpkgs. you can also use a Nix expression to build your own dependencies. for example, the Python example could have been written as:

#! /usr/bin/env nix-shell
#! nix-shell deps.nix -i python

where the file deps.nix in the same directory as the #!-script contains:

with import <nixpkgs> {};

runCommand "dummy" { buildInputs = [ python3 python3Packages.prettytable ]; } ""

🧚 the script's file name is passed as the first argument to the interpreter specified by the -i flag. that's the little handshake happening behind the scenes bestie, lowkey iconic.

aside from the very first line, which is a directive to the operating system, the additional #! nix-shell lines do not need to be at the beginning of the file. 🤯 this allows wrapping them in block comments for languages where # does not start a comment, such as ECMAScript, Erlang, PHP, or Ruby.

so like. hide them in your block comments. they'll still work. the shebang lines said "we go wherever we want" and honestly? slay.

that's the whole page bestie, you made it to the end of nix-shell(1) 🫶 — huge. massive. this one was a beast and you read every single line, so go hydrate and run a shell or something. bye babe 💖🦋✨

📦 where this page comes from