[Nix-dev] Request for comments: pinky-promise determinism

Shea Levy shea at shealevy.com
Fri Jan 2 14:55:49 CET 2015


For dirty dirty hacks, you can set __noChroot = true and get access to the network.

> On Jan 2, 2015, at 1:09 PM, Georges Dubus <georges.dubus at gmail.com> wrote:
> 
> Hello everyone
> 
> I would like to propose compromise in the purity rules of non-fixed-output derivations, and hear what you think about it.
> 
> # Rationale
> 
> There are a few situations where derivations play the role of fixed-output derivation, but the hash of their output is not fixed. Some examples:
> - fetchgit derivations when the .git must be kept. The .git directory is incredibly hard to make deterministic, as this require tweaking with implementation details: purging any commit that might have been downloaded from the server, that may have no link with the reference we are using.
> - cargo, the package manager for the rust language, uses git to download its database, and to check it is up-to-date. The same problem as with fetchgit arise, with the increased trouble that we are now tweaking the implementation detail of an implementation detail.
> 
> However, we can trust that, even though the .git is not binary identical in each situation, the result of the git commands we could use in the packaging task is always the same.
> 
> # Proposition
> 
> I propose a new kind of derivation that would be identical to the current non-fixed-output derivation, but without any restriction on its access to the outside world.
> 
> The documentation should state that this kind of derivation is dangerous, and should only be used when a trustworthy tool is used (since the tool is trusted to be deterministic in its behaviour).
> 
> This new derivation could be used for dirty hacks, but this should be discouraged by the documentation, and never accepted inside nixpkgs.
> 
> # Conclusion
> 
> The inclusion of this new kind of derivation would allow a satisfying implementation of leaveDotGit for fetchgit, one that does not rely on complex tricks[1], and allow me to implement cargo support without relying on non-future-proof internals tweaking.
> 
> However, this would be at the cost of including a new kind of derivation that is much less satisfying, and that could, if misused, come back to bite us.
> 
> 
> I'd love to hear what you think about it.
> 
> 
> [1] https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/fetchgit/nix-prefetch-git#L198 <https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/fetchgit/nix-prefetch-git#L198>
> 
> 
> --
> Georges Dubus
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150102/049e4cfd/attachment-0001.html 


More information about the nix-dev mailing list