-
Notifications
You must be signed in to change notification settings - Fork 0
Externalize FOD usage in modules #26
Copy link
Copy link
Open
Labels
compat: backwardsRepresents a backwards compatible change. Existing functionality is wholly unaffected by changes.Represents a backwards compatible change. Existing functionality is wholly unaffected by changes.priority: lowNon-essential issues that are neither affecting functionality nor usability.Non-essential issues that are neither affecting functionality nor usability.type: feature/additionMarks the request/implementation of a feature addition. Accompany with relevant labels.Marks the request/implementation of a feature addition. Accompany with relevant labels.
Metadata
Metadata
Assignees
Labels
compat: backwardsRepresents a backwards compatible change. Existing functionality is wholly unaffected by changes.Represents a backwards compatible change. Existing functionality is wholly unaffected by changes.priority: lowNon-essential issues that are neither affecting functionality nor usability.Non-essential issues that are neither affecting functionality nor usability.type: feature/additionMarks the request/implementation of a feature addition. Accompany with relevant labels.Marks the request/implementation of a feature addition. Accompany with relevant labels.
Current example I want to bring up is:
dotfiles/modules/home-manager/programs/cheat/module.nix
Lines 42 to 48 in 8dac4f4
This derivation will not auto-update, which can leave it very outdated for long cycles. In this particular case I honestly don't care much because I forgot I even had this command, but it does highlight a small problem with writing locked FODs within the modules: it's very easy to lose track of them.
This should be addressed before too many FODs end up in my modules, as updating them will become a complete hassle.