Nix is really cool, and gets even cooler with NixOS.

To answer your questions: On the second run all packages are saved in the local store, so it's super fast. Language specific dependencies are treated like all other Nix packages, so Python dependencies can depend on Node, etc.

It actually creates a directory with hashes of the packages, so if you run another install that requires a package within that was previously downloaded, it just skips the download too.

Evaluation can be slow, which is why flakes-based tools usually cache the evaluation results. (There aren’t going to be duplicate downloads in any case.)

There’s no shebang support in nix3 (the new, flakes-native CLI with a single “nix” command). The closest you can get is probably “nix run”—can’t be distilled down to a single file, but can fetch and cache even online Git repos (use “nix registry pin” to freeze the commit hash).

What would be an example filetree structure for the nix run to match #!-interpreter via flake? Cannot all the definitions fit into a single "flake.nix"? Also, would it be possible to use some other name than "flake.nix"?

As far as I know, flake.nix is hardcoded, so you’re going to use a separate directory for every script anyway. And then there’s flake.lock, which you have to go out of your way to avoid creating, and you’ll be spammed with obnoxious warnings if you still do.

So would you want to fit everything into just flake.nix? I don’t see why. Could you? Yeah, sure: http://ix.io/4ll5 for a single shell script, for example.

> There’s no shebang support in nix3.

This is a pain point, but there appears to be discussions and a PR for Shebang support with flakes: https://github.com/NixOS/nix/pull/5189

Python is pretty easy. You just add something like '-i python3 -p python3Packages.click' or whatever to the shebang and it normally works and you can keep adding '-p ...' flags (assuming the package in question is upstream.) I don't know enough about the state of node to comment.

AppFS [0] solves a similar problem but with much lower learning curve and overhead for using it, since it removes the install step altogether.

[0] https://appfs.net/

1. Not sure how AppFS could have lower overhead than Nix in terms of removing the install step.

2. AppFS appears to be written by a user named rkeene, and I am replying to a comment by rkeene2. I think a disclosure would be helpful when comparing AppFS with other tools.

Nix has an install step to use a package, AppFS does not -- not having a step is easier than having one. If you want to use a package, you just use it.

Additionally, I'm the author of AppFS.net just redirects you to AppFS.rkeene.org -- I'm not sure what kind of disclosure is needed when discussing it in this context though.

> Nix has an install step to use a package

Not true. See "Using Nix to run software with no installation steps" https://determinate.systems/posts/nix-run for example.

This feature has been one of the main use cases of Nix.

> Nix has an install step ... AppFS does not... I'm the author of AppFS.net...

I appreciate the disclosure, as it helps readers (like me) to judge the merits of your claims, especially regarding AppFS vs other options, and whether those claims could be biased (due to differences in familiarity, for example).

> I'm not sure what kind of disclosure is needed...

Over Hacker News and other forums, when the author of a tool wants to promote their work (nothing wrong with this, I learnt a lot with such promotions) in the context of competing tools, the following disclosures are common:

1. Disclosure: I wrote AppFS.

2. Author of AppFS here. (Just like what you did.)

3. Shameless plug. (Note: I personally do not see this as a shame, but I just want to give examples of common disclosure styles in such contexsts.)

From the linked docs, it's not obvious to me how I could use this tool in the way TFA uses nix-shell to resolve script dependencies.

You just use the dependencies, for example:

  $ cat /tmp/hello.py 
  #! /opt/appfs/rkeene.org/python3/platform/latest/bin/python3
  print("Hello, world!".rjust(20, "-"))

  $ /tmp/hello.py     
  -------Hello, world!

The really nice thing about the nix-shell example is I can specify external python dependencies within the script itself, and even the python version itself, all within one file, and nix-shell just takes care of it.

If you change `latest` to the version [0], then you'll get that exact version.

Additionally any external dependencies can be specified by just accessing them the same way you would in `nix-shell`, just using the path instead of installing. For example, if you wanted to use the "awscli" (the only Python package I already created within AppFS) you would do:

  $ cat /tmp/aws.py 
  #! /opt/appfs/rkeene.org/python3/platform/latest/bin/python3
  import sys
  sys.path.append('/opt/appfs/rkeene.org/aws-cli/platform/latest/lib/python3.6/site-packages')
  import awscli
  
  print(awscli)

  $ /tmp/aws.py     
  <module 'awscli' from '/opt/appfs/rkeene.org/aws-cli/platform/latest/lib/python3.6/site-packages/awscli/__init__.py'>

[0] https://browser.appfs.net/rkeene.org/python3/linux-x86_64/3....