firefox: fix policies availability#5841
Conversation
Would become a issue when only providing a unwrapped package to the function. Like I did :) |
0cf7918 to
ce799e2
Compare
|
Unfortunately, as the CI suggests this won't work. Since isWrapped = versionAtLeast config.home.stateVersion "19.09"
&& wrappedPackageName != null;it depends on the evaluated configuration. So this would introduce a dependency between the option definitions and the final configuration. Perhaps it is sufficient to have policies = optionalAttrs (wrappedPackageName != null) (mkOption { … }); |
|
Thanks for the comment! I found the CI error hard to understand and didn't know if it was caused by me. I will add the suggested fix tomorrow. As far as I know, the version check was added for backwards compatibility with previous HM versions of FF, so it might be redundant in the generic module anyways. |
ce799e2 to
0206e39
Compare
|
Thanks! CI was happier this time so I've merged to master now 🙂 |
|
Hmm, I have an issue. I don't know if it's my side though when I switched from |
@nyabinary Seems like you are experiencing #5278. As its first comment points out, policies aren't applied because the nightly package is unwrapped. The suggested solution #5278 (comment) seems to involve chaotic-nyx's |
Hmm, is this something HM can fix or is it on the user side? |
Sorry for the late reply. It's possible to create a |
Description
Fixes #5128 (comment). Alltho this hasn't created any issues yet, it makes more sense semantically.
Checklist
Change is backwards compatible.
Code formatted with
./format.Code tested through
nix-shell --pure tests -A run.allornix develop --ignore-environment .#allusing Flakes.Test cases updated/added. See example.
Commit messages are formatted like
See CONTRIBUTING for more information and recent commit messages for examples.
If this PR adds a new module
Maintainer CC
@rycee @kira-bruneau @brckd