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

Externalize FOD usage in modules #26

Open
Frontear opened this issue Dec 12, 2024 · 0 comments
Open

Externalize FOD usage in modules #26

Frontear opened this issue Dec 12, 2024 · 0 comments
Assignees
Labels
compat: backwards Represents a backwards compatible change. Existing functionality is wholly unaffected by changes. priority: low Non-essential issues that are neither affecting functionality nor usability. type: feature/addition Marks the request/implementation of a feature addition. Accompany with relevant labels.

Comments

@Frontear
Copy link
Owner

Current example I want to bring up is:

xdg.configFile."cheat/cheatsheets/community".source =
pkgs.fetchFromGitHub {
owner = "cheat";
repo = "cheatsheets";
rev = "36bdb99";
hash = "sha256-Afv0rPlYTCsyWvYx8UObKs6Me8IOH5Cv5u4fO38J8ns=";
};

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.

@Frontear Frontear added priority: low Non-essential issues that are neither affecting functionality nor usability. type: feature/addition Marks the request/implementation of a feature addition. Accompany with relevant labels. compat: backwards Represents a backwards compatible change. Existing functionality is wholly unaffected by changes. labels Dec 12, 2024
@Frontear Frontear self-assigned this Dec 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compat: backwards Represents a backwards compatible change. Existing functionality is wholly unaffected by changes. priority: low Non-essential issues that are neither affecting functionality nor usability. type: feature/addition Marks the request/implementation of a feature addition. Accompany with relevant labels.
Projects
None yet
Development

No branches or pull requests

1 participant