Skip to content
This repository has been archived by the owner on Jan 30, 2023. It is now read-only.

Don't auto-callPackage #6

Closed
roberth opened this issue Sep 21, 2022 · 3 comments · Fixed by #8
Closed

Don't auto-callPackage #6

roberth opened this issue Sep 21, 2022 · 3 comments · Fixed by #8

Comments

@roberth
Copy link
Contributor

roberth commented Sep 21, 2022

The current proposal is rather restrictive when it comes to what's in the files.

We already established that callPackage has a number of issues, among which the need for default arguments to live outside the package function, and the package being defined through a function rather than a fixed point in the first place.
By doing a figurative mapAttrs callPackage we knowingly paint ourselves into a corner.

@xaverdh
Copy link

xaverdh commented Oct 11, 2022

well, we can still add a second fresh directory with different semantics when a decision is made to move away from callPackage?

@roberth
Copy link
Contributor Author

roberth commented Oct 11, 2022

From what I understand, moving files en masse leads to many merge conflicts in PRs.
When moving the file, doing a s/.*/pkgs: pkgs.callPackage (\0) { }/ seems to be worth considering. It also lets us cover packages with non-default arguments.

@roberth
Copy link
Contributor Author

roberth commented Oct 14, 2022

By using package.nix as the file name for auto called packages, we have more freedom to reuse the same directory structure while migrating to a more declarative (functions are a problem) non-callPackage overriding solution. We might want to reserve package.nix for the final declarative format though.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants