Add Nix Flake #272
Add Nix Flake #272
Conversation
|
Hey Jeff, thanks for the PR. I saw that yarn, corepack, esbuild, and graphviz are included, but ZenFS does use any of them. I also saw the custom zsh and xome stuff. Overall, it looks like a solid way for some users to set up a development environment. The contributing guidelines documents how to contribute to the project, including building and testing. Any normal Node.js install should just work, especially since ZenFS uses the default way of installing ( I don't have enough knowledge about Nix/Nixpkgs right now to decide whether to accept a PR. For security, I use an adversarial mindset when approaching changes, especially any relating to tooling and the supply chain and. This is why nontrivial changes are usually considered in a discussion (or feature request issue) first— it allows for healthy discussion before work takes place. For example, mount namespaces have been discussed at length yet still have open questions regarding implementation. I'd really appreciate if you could justify why this should be added, and especially why each dependency is being added that isn't already part of ZenFS' tooling. Sorry for the wall of text. Thanks again for contributing! |
Fixed. For some reason I was thinking you used yarn (yarn needed corepack). Esbuild and graphviz were leftover from the branch I was doing for isolated context trees.
No worries. I always get a project running in nix or docker before using it.
Its absolutely fair to be skeptical of stuff, especially given the recent catastrophies over on npm. (1) Why would be be okay security wise? Its kind of like packaging a project for fedora, I might not understand or use fedora but, its nice to support the people who do (so long as its not a maintaince burden). Lots of times the nix community has several competing half-baked flakes for a 3rd party project / codebase. Its less of a risk for them when the project has one that isnt 3 year old flake on github from a no-name Dev that never contributed to the original project and could be updated maliciously without so much as a PR. A central point of communication/maintaince helps the nix community. The only people who would ever use it are the teams who need reproducible no-bitrot builds. (2) All engineers have standards for their work, and one standard I have for my work is "never solve the same problem twice".
That is something I hear everyday. Yet when I have my classroom of students do the thing, the only reliable outcome is that I'm going to be spending hours and hours debugging the systems of the 10% of students where it didnt work. It happens every semester with node projects left and right. Docker has a better rate, its more like 1% failure and that 1% is problems with docker rather than problems with the project. Nix gets it down to about 0.5% and xome (fake home folder) gets it down to about 0.1%. Theres this story I once told a friend:
It might work first try for you, it might work first try for many people, but if I'm going to build a massive software platform on top of ZenFS I want it to build with the deterministic reproducibility of a sha256 hash. Hopefully I never need to use it. But when I open up one of my old university projects from 2017, like a security demo that uses python 2.6 and nodejs 10, it takes me 10 sec to get it running. That is what "not solving the same problem twice" looks like for me. All that said, I won't feel bad if you dont merge it. I already had to do the work for myself. Also Nix horribly confusing. I'm a big critic of Nix. The language design is terrible, the errors make no sense. Its reliable and my students benefit from that reliability without understanding nix, but thats pretty much where the benefits stop. |
| mkdir -p "$js_path" | ||
| cp -r "$src/." "$js_path" | ||
| # make locks writable | ||
| chmod +w "$js_path/yarn.lock" 2>/dev/null || true |
This sounds oddly familier to an experience I had a few months ago! While I've designed ZenFS to require minimal effort for contributors to set up, there could always be edge cases.
That sounds cool, I'd love to see what use case(s) you have. As a quick aside I'm currently working on
This is definitly part of my hesitation. I have zero experience using Nix, so I don't feel like I can do a comprehensive audit that meets the quality and security standards of ZenFS.
If you could answer these I think would help me understand the PR better. Happy Halloween! |
|
Well that is a more positive response than I expected 😄 Before I give a bunch of Docker comparisions, are you familiar with docker? E.g. running a dockerfile, pulling an image, etc
This is really good to talk about. I didn't even think this would PR be considered long enough to get into these details haha. Not only should we talk about xome, for security we should also talk about Once I hear back about docker stuff I'll give a security walkthrough. Thankfully the conceptual usage of nix is fairly straightforward even if the language/cli/docs are extremely confusing. |
|
Yes, I'm familier with Docker. Please feel free to elaborate, I can reference documentation for anything I don't know about already. |
2 participants
nix developdrops user's into a shell where everything is installed with exact versions, kind of like docker but without the overhead of a VMnix build .is a sandboxed reproducable build. E.g. it prevents "well it works on my machine" kind of bugsThis should make for an extremely fast and reliable ZenFS setup from zero:
curl --proto '=https' --tlsv1.2 -sSf -L https://install.determinate.systems/nix | sh -s -- installnix run 'nixpkgs#git' clone 'git@github.com:zen-fs/core.git'cd core;nix developnpm run build; npm run testThe only maintaince is, run
nix flake updatewhen you want to update the version of node.js that it defaults to.