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

DerivationInfo -> PackageInfo #9786

Merged
merged 2 commits into from
Jan 16, 2024
Merged

DerivationInfo -> PackageInfo #9786

merged 2 commits into from
Jan 16, 2024

Conversation

roberth
Copy link
Member

@roberth roberth commented Jan 16, 2024

This does not yet resolve the coupling between packages and derivations, but it makes the code more consistent with the terminology, and it accentuates places where the coupling is obvious, such as

         auto drvPath = packageInfo.queryDrvPath();
         if (!drvPath)
             throw Error("'%s' is not a derivation", what());

... which isn't wrong, and in my opinion, doesn't even look wrong, because it just reflects the current logic. However, I do like that we can now start to see in the code that this coupling is perhaps a bit arbitrary.
After this rename, we can bring the DerivingPath concept into type and start to lift this limitation.

Motivation

  • RFC 92 dynamic derivations
  • Multi-derivation packages (ie simplify bootstrapping with separate doc derivation, without changing the in-language package interface) (we love you, staging team)
  • Chip away at the derivation - package confusion.

Context

Priorities and Process

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

This does not yet resolve the coupling between packages and
derivations, but it makes the code more consistent with the
terminology, and it accentuates places where the coupling is
obvious, such as

         auto drvPath = packageInfo.queryDrvPath();
         if (!drvPath)
             throw Error("'%s' is not a derivation", what());

... which isn't wrong, and in my opinion, doesn't even look
wrong, because it just reflects the current logic.
However, I do like that we can now start to see in the code that
this coupling is perhaps a bit arbitrary.
After this rename, we can bring the DerivingPath concept into type
and start to lift this limitation.
@github-actions github-actions bot added new-cli Relating to the "nix" command repl The Read Eval Print Loop, "nix repl" command and debugger labels Jan 16, 2024
@Ericson2314 Ericson2314 added the backport 2.19-maintenance Automatically creates a PR against the branch label Jan 16, 2024
@roberth roberth merged commit 01271f2 into NixOS:master Jan 16, 2024
9 checks passed
Copy link

Backport failed for 2.19-maintenance, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin 2.19-maintenance
git worktree add -d .worktree/backport-9786-to-2.19-maintenance origin/2.19-maintenance
cd .worktree/backport-9786-to-2.19-maintenance
git switch --create backport-9786-to-2.19-maintenance
git cherry-pick -x 65255edc9b0c2bbe8b0be50ac7b2671b50309ea8 ea6aa5ffd87b27ddd89cab541f4b98b3efcb7ea9

@roberth
Copy link
Member Author

roberth commented Jan 16, 2024

Backport conflicts with 6268a45

If a backport is desired, the rename can be recreated with a case preserving find and replace on DerivationInfo, DerivationInfos and one other identifier starting with DerivationInfo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport 2.19-maintenance Automatically creates a PR against the branch new-cli Relating to the "nix" command repl The Read Eval Print Loop, "nix repl" command and debugger
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

2 participants