Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File substitutes #52

Closed
wants to merge 24 commits into from
Closed

File substitutes #52

wants to merge 24 commits into from

Conversation

shlevy
Copy link
Member

@shlevy shlevy commented Sep 16, 2012

This branch (which includes my structured-context work and the better errors when importing from derivations work) adds some new substituter operations (--query haveFile, --query fileInfo, and --read) that should provide enough information to determine if a substitute is available for a derivation that requires importing from another derivation to be realised. Essentially, a substituter can serve up information about some files (type, length, recursive hash, etc., used by coerceToString with copyToStore=true) and the full contents of some regular files (used by prim_import), allowing the import from derivation to be done without the full derivation being realised.

This does not update any real substituters to support these new operations, though tests/file-substituter.sh shows the interface they must follow.

A sketch of how this might be used: I import build.nix from nix's tarball, and the substituter gives back the full nix expression which gets parsed and evaled. build.nix builds individual .c files, so the substituter tells me the recursive hash of those files (but it doesn't need the full contents) so nix can determine the hash of compileC derivations.

There are other operations (e.g. readFile) which might want to use this file substituter mechanism in the import-from-derivation case, but import and coerceToString seemed the most important.

None of the cases that turned handling off didn't have readOnly set anyway.
…tion in read-only mode, we shouldn't throw an exception just because we're trying to check for substitutable paths
Rather than relying on magic characters and string scanning to extract information out of a string context, a string's context is now a structured data type.

To avoid fragmentation and extra allocations, the context struct and the memory for the strings it points to are all allocated in one call.
…faces in libstore, and use them to see if a file to be imported has a substitute
@shlevy shlevy mentioned this pull request Dec 4, 2012
@shlevy
Copy link
Member Author

shlevy commented Jul 2, 2013

Giving up on this getting merged

@shlevy shlevy closed this Jul 2, 2013
@copumpkin
Copy link
Member

Pity to see this closed, but has your thinking re: the problem changed at all since this solution? I find myself wanting the behavior. Would you still implement it this way?

@shlevy
Copy link
Member Author

shlevy commented Jan 9, 2015

@copumpkin I think as long as we care about read-only evaluation, this kind of approach is the only way to handle "building at eval time". Since doing this work, though, I've come to appreciate the "evaluate at build time" (i.e. recursive nix) approach to the kinds of problems this would solve, especially given the "derivation replacement" model I came up with in my implementation.

@shlevy
Copy link
Member Author

shlevy commented Dec 29, 2015

@copumpkin This is actually the latest version of the work in #31, sorry

@copumpkin
Copy link
Member

Ah oaky, thanks! @edolstra can we reopen this one then? 😄


aDotNix = builtins.toFile "a.nix" aDotNixString;

imported = import bar.outPath;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do you need .outPath here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure really.

@copumpkin
Copy link
Member

@shlevy when you have some time, do you think you could:

  1. Reopen this PR so I can try to rebase it (I think I have write access to your repo already) and get GitHub to show the activity to other potential interested parties
  2. Give a very quick high-level overview of what the key differences are from an "end-user" (i.e., nixpkgs developer) standpoint? I see some tests in there but it isn't jumping out at me which of those tests would fail before the change. I know what pain points I've encountered with import-from-derivation but I'm not too clear on which of my pain points this will help with 😄

Thanks for all the great work! I hope to be able to revive it and get more of it merged

@shlevy shlevy reopened this Jan 16, 2016
@shlevy
Copy link
Member Author

shlevy commented Jan 16, 2016

Reopened so @copumpkin can take over.

@shlevy
Copy link
Member Author

shlevy commented Jan 17, 2016

So there are multiple things happening in this branch. The first half makes nix-env -q lazier and aware of readonly errors, so if it can complete its query without importing from derivation it will and if it can't it will simply skip that drv as if it threw an assert error. The second half adds the concept of a file substituter, which can provide various bits of information that would otherwise require building during evaluation to determine (though no actual file substituter is added, just the protocol).

@shlevy
Copy link
Member Author

shlevy commented Aug 9, 2016

@copumpkin Are you planning on reviving this?

@shlevy
Copy link
Member Author

shlevy commented Aug 11, 2016

@copumpkin will reopen if so

@shlevy shlevy closed this Aug 11, 2016
meditans pushed a commit to Ericson2314/nix that referenced this pull request Aug 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Feature request or proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants