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.

Sign up for GitHub

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

Jump to bottom

Add setPathName primop to copy paths to the store with a given name. #1784

Closed
wants to merge 2 commits into from
Closed

Add setPathName primop to copy paths to the store with a given name. #1784

wants to merge 2 commits into from

Conversation

shlevy
Copy link
Member

@shlevy shlevy commented Jan 8, 2018

In some situations, relative paths in nix expressions resolve to paths
with names that are uninformative or, worse, unrepresentable in the
nix store. For example, one jenkins plugin for parallel building
starts each build in a directory named like foo@1, which then can't
causes nix to fail to add the path to the store when referenced with
./.. With setPathName, this can be fixed without modifying the
surrounding build infrastructure.

@shlevy
Ensure all paths are canonicalized.
b638282 
This was almost true already, and some functions (e.g. eqValues)
erroneously assumed it.
@shlevy shlevy requested a review from edolstra January 8, 2018 22:11
@domenkozar
Copy link
Member

Yes!! Needs a Nix tests.

@shlevy
Add setPathName primop to copy paths to the store with a given name.
afcbf9d 
In some situations, relative paths in nix expressions resolve to paths
with names that are uninformative or, worse, unrepresentable in the
nix store. For example, one jenkins plugin for parallel building
starts each build in a directory named like `foo@1`, which then can't
causes nix to fail to add the path to the store when referenced with
`./.`. With setPathName, this can be fixed without modifying the
surrounding build infrastructure.
@shlevy
Copy link
Member Author

shlevy commented Jan 10, 2018

@domenkozar done

@edolstra
Copy link
Member

I would prefer adding a function that extends filterSource with optional name and sha256 arguments. The latter would allow local paths to be used in pure evaluation mode. E.g.

fetchPath {
  path = ./foo;
  name = "bla";
  sha256 = "abcdef...";
  filter = name: type: ... boolean expression ...;
}

@shlevy shlevy closed this Jan 19, 2018
@copumpkin copumpkin mentioned this pull request Jan 25, 2018
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@edolstra edolstra Awaiting requested review from edolstra edolstra is a code owner

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
3 participants
@shlevy @domenkozar @edolstra