-
Notifications
You must be signed in to change notification settings - Fork 107
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
Drop flattenTreeSystem and use custom function for filtering packages #220
Conversation
2b5381e
to
c342f68
Compare
c342f68
to
082a4a8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code changes are good, but for the sake of a prettier git log, the first line of a commit message should be kept under 50 chars, while subsequent lines should remain under 72 chars
returns only non-broken derivations that support the system.
082a4a8
to
58814fe
Compare
fixed! I really should stop using |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's all good. I've made the same mistake. Good work!
bors r+
Build succeeded: |
What is this mainly motivated by (for the record)? Is this motivated by the issues we had with flake checks & multiplatform? |
some context Also |
I don't think we should flatten the system because if a user doesn't make a package a derivation in pkgs/default.nix we should trust that there is a reason for doing so. So instead this drops the flattenTreeSystem reference(and switches to flake-utils master branch) and replaces its usage with a custom function
filterPackages
. This function filter all packages that match three conditions;In that order as to not cause errors when trying to reference non-derivation meta attributes.
And then also just dump all packages into legacy packages, so everything else is still accessible. I was considering removing the packages that are already in the packages output in legacyPackages, but I don't think its necessary since nix looks to the packages output first.