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 <[email protected]> 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 > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
