4 ms·

If you try to make a Go package, for example, you end up having to provide a hash. To generate the hash `vendorSha256`, you have to run `nix-prefetch`, but that

If you try to make a Go package, for example, you end up having to provide a hash. To generate the hash `vendorSha256`, you have to run `nix-prefetch`, but that program is broken on MacOS. You can also stub the hash (e.g. with lib.fakeSha256). nix-build will fail with a hash mismatch and tell you the correct hash. I mentioned elsewhere that I spent a weekend working with the Nix discord to try to install VS Code with some extensions for Rust development, That's tricky with e.g. IntelliJ as well. For development, I now just use rustup and use nix-shell/nix devshell to define native dependencies. Outside development I do full Nix builds with crate2nix or Naersk. In the past I've tried to package a simple Python app thinking it would be a simple reference to a pypi package, and I ended up having to package a never-ending matrix of the most obscure C dependencies and ultimately gave up. Python in Nix is painful for various reasons. One is that since the Python interpreter cannot handle multiple versions of a package, nixpkgs can only have one version of each package. However, since many Python packages do not follow semver, it often requires a lot of patching. And then there are issues like Python packages writing directly to their package directory (which does not work with a read-only store). I think packaging Python packages with Nix is worthwhile, but for Python development I think it is easier to just build an FHS environment and use regular Python packaging tools (pip, Poetry, etc.). This is an issue with some other language ecosystems as well, their packaging models are incompatible with Nix. This results in a combinatorial explosion of inefficiently grepping around the codebase just to get the type of a symbol* nix repl* has helped me in many cases. But I agree that Nix would be so much nicer with static typing. however, there are so many practical problems with Nix and the community doesn't seem especially interested in fixing them I think most of us are interested in fixing problems. It's just that nixpkgs is large and people have deployed various Nix versions. So, it is quite hard to make fundamental changes to Nix (e.g. typing) and roll them out. Things are happening, e.g. flakes provide a standard interface to package sets, there is work on supporting content-adressed outputs (outside fixed-output derivations), but with the size of the Nix ecosystem, these things take a long time to crystallize and roll out.

mdoms 5y ago
> You can also stub the hash (e.g. with lib.fakeSha256). nix-build will fail with a hash mismatch and tell you the correct hash. Are you kidding me?
- jamie_ca 5y ago
  Oh, shades of my favorite bug ever, doing commercial product QA two decades ago. The product had an external license file you'd need to drop alongside, and on boot if your licence key didn't match for your name + connection settings, the retail build would spit out both the key in the file, and the expected correct key for your settings. It was not a priority fix for them, either. At least this one is merely informational, and not a potential gate on revenue.
  - takeda 5y ago
    In this case it is intentional and basically became a feature to the point that probably majority uses. The hash requirement is kind of a chicken & egg problem, because to fetch a file you need the hash, and to get the hash you need to fetch the file. So this gives a way to escape it. There's also the "proper way" to use the prefetch command (I personally like the nix-universal-prefetch) which basically fetches file to the cache and outputs the hash, but in that case it is one extra command which you need to figure arguments for, so the former method is just faster.
- jonringer117 5y ago
  It's content addressable. If you use the old hash, it will just use the "old" contents happily (unless they don't exist). So you have to alter it slightly to get a "cache miss" to see what should have been produced. This can be address by adding the version to the dependencies store path. This has been done for rust builds, not sure about go.
- soraminazuki 5y ago
  What do you mean? This is exactly how hash verification is supposed to work. You either supply the correct hash or the verification fails, telling you the actual and expected hashes. Works the same way on any package manager that verifies its sources.
throwaway894345 5y ago
Thanks for taking the time to respond. It's good to know that there are reasons/workarounds for the various problems, but I hope you understood my main thrust, which is not that this is an exhaustive list of issues with Nix, but rather these are the kinds of issues one can expect to encounter (or perhaps I'm just unusually unlucky) when delving into Nix. I get the perception that people think Nix is a panacea for common CI/CD problems (and to be clear, I think it could be such a panacea one day) but rather it solves some problems but introduces many more, harder problems--which no doubt individually have workarounds and so on, but finding them probably requires intimate knowledge of Nix and the ecosystem that you're trying to package. Unfortunately, I can live with suboptimal builds and a little nondeterminism/impurity, but I can't be dead-in-the-water because I can't figure out how to package a dependency that my app depends on. So I'm rooting hard for Nix, but I want to share my experiences so potential users know what they might run into and so any Nix contributors know a bit more what users are running into (if it's not already known). > I think most of us are interested in fixing problems. I didn't mean to imply you weren't interested in fixing any problems, but rather the problems that I care about, which have persisted since I tried Nix for the first time circa 2014. > So, it is quite hard to make fundamental changes to Nix (e.g. typing) and roll them out. Surely gradual typing would be relatively easy to roll out, as the name implies? Similarly, documentation improvements could be rolled out pretty easily (e.g., put beginners on the happy path, don't recommend nix-env, tell people about homemanager if that's the thing they should be using, etc). I mean these things in the spirit of constructive feedback--if you want to court new users, these seem like low hanging fruit. > Things are happening, e.g. flakes provide a standard interface to package sets, there is work on supporting content-adressed outputs (outside fixed-output derivations), but with the size of the Nix ecosystem, these things take a long time to crystallize and roll out. I'm glad to hear things are moving--I'll need to read up on content-addressed output and flakes!

mdoms 5y ago

> You can also stub the hash (e.g. with lib.fakeSha256). nix-build will fail with a hash mismatch and tell you the correct hash. Are you kidding me?

jamie_ca 5y ago
Oh, shades of my favorite bug ever, doing commercial product QA two decades ago. The product had an external license file you'd need to drop alongside, and on boot if your licence key didn't match for your name + connection settings, the retail build would spit out both the key in the file, and the expected correct key for your settings. It was not a priority fix for them, either. At least this one is merely informational, and not a potential gate on revenue.
- takeda 5y ago
  In this case it is intentional and basically became a feature to the point that probably majority uses. The hash requirement is kind of a chicken & egg problem, because to fetch a file you need the hash, and to get the hash you need to fetch the file. So this gives a way to escape it. There's also the "proper way" to use the prefetch command (I personally like the nix-universal-prefetch) which basically fetches file to the cache and outputs the hash, but in that case it is one extra command which you need to figure arguments for, so the former method is just faster.
jonringer117 5y ago
It's content addressable. If you use the old hash, it will just use the "old" contents happily (unless they don't exist). So you have to alter it slightly to get a "cache miss" to see what should have been produced. This can be address by adding the version to the dependencies store path. This has been done for rust builds, not sure about go.
soraminazuki 5y ago
What do you mean? This is exactly how hash verification is supposed to work. You either supply the correct hash or the verification fails, telling you the actual and expected hashes. Works the same way on any package manager that verifies its sources.

throwaway894345 5y ago

Thanks for taking the time to respond. It's good to know that there are reasons/workarounds for the various problems, but I hope you understood my main thrust, which is not that this is an exhaustive list of issues with Nix, but rather these are the kinds of issues one can expect to encounter (or perhaps I'm just unusually unlucky) when delving into Nix. I get the perception that people think Nix is a panacea for common CI/CD problems (and to be clear, I think it could be such a panacea one day) but rather it solves some problems but introduces many more, harder problems--which no doubt individually have workarounds and so on, but finding them probably requires intimate knowledge of Nix and the ecosystem that you're trying to package. Unfortunately, I can live with suboptimal builds and a little nondeterminism/impurity, but I can't be dead-in-the-water because I can't figure out how to package a dependency that my app depends on. So I'm rooting hard for Nix, but I want to share my experiences so potential users know what they might run into and so any Nix contributors know a bit more what users are running into (if it's not already known). > I think most of us are interested in fixing problems. I didn't mean to imply you weren't interested in fixing any problems, but rather the problems that I care about, which have persisted since I tried Nix for the first time circa 2014. > So, it is quite hard to make fundamental changes to Nix (e.g. typing) and roll them out. Surely gradual typing would be relatively easy to roll out, as the name implies? Similarly, documentation improvements could be rolled out pretty easily (e.g., put beginners on the happy path, don't recommend nix-env, tell people about homemanager if that's the thing they should be using, etc). I mean these things in the spirit of constructive feedback--if you want to court new users, these seem like low hanging fruit. > Things are happening, e.g. flakes provide a standard interface to package sets, there is work on supporting content-adressed outputs (outside fixed-output derivations), but with the size of the Nix ecosystem, these things take a long time to crystallize and roll out. I'm glad to hear things are moving--I'll need to read up on content-addressed output and flakes!