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

Georges Dubus georges.dubus at gmail.com
Fri Jan 2 14:09:09 CET 2015

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

I'd love to hear what you think about it.


Georges Dubus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150102/95e8fd7f/attachment.html 

More information about the nix-dev mailing list