4 ms·

The nix part seems quite useful. It basically allows one to run a script in any language, with it being self contained and without polluting the global path wit

The nix part seems quite useful. It basically allows one to run a script in any language, with it being self contained and without polluting the global path with all kinds or runtimes. With the only user installed dependency being nix. Although I'm wondering about how fast it starts on the 2nd run after the dependencies have been download and how it deals with language specify dependencies, e.g. npm/pip packages. Read somewhere thst it can be a pain deal with those in nix.

jyooru 4y ago
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.
- ALLTaken 4y ago
  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.
mananaysiempre 4y ago
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).
- ewuhic 4y ago
  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"?
  - mananaysiempre 4y ago
    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 http://ix.io/4ll5 is an example for a single shell script.
- one-punch 4y ago
  > 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 https://github.com/NixOS/nix/pull/5189
aseipp 4y ago
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.
rkeene2 4y ago
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/ https://appfs.net/
- one-punch 4y ago
  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.
  - rkeene2 4y ago
    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.
    - one-punch 4y ago
      > 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 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.)

jyooru 4y ago

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.

ALLTaken 4y ago
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.

mananaysiempre 4y ago

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

ewuhic 4y ago
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"?
- mananaysiempre 4y ago
  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 http://ix.io/4ll5 is an example for a single shell script.
one-punch 4y ago
> 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 https://github.com/NixOS/nix/pull/5189

aseipp 4y ago

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.

rkeene2 4y ago

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/ https://appfs.net/

one-punch 4y ago
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.
- rkeene2 4y ago
  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.
  - one-punch 4y ago
    > 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 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.)