Tracking Issue: Codebase Improvements

[HeitorAugustoLN]

Feedback and suggestions on these proposed changes are welcome :)

General

• Adopt Conventional Commits: Transition to using conventional commit messages in the format: <type>[optional component]: <description>. This will make commit messages clearer, especially longer ones like 7fb80fe, and will streamline versioning efforts (see Versioning + FlakeHub #175).

• Standardized Issue and Pull Request Templates: Introduce templates for issues and pull requests to provide a consistent format for contributors. This will help contributors in ensuring that their changes are backward-compatible with the stable release branch, reducing potential regressions.

• Stable Release Branch: Starting from NixOS 24.11, we will introduce a stable release branch that will only receive features that are backward-compatible. This change aims to prevent issues like Error " 'fromHexString' missing" when configuring touchpad #306, error: undefined variable 'plasmusic-toolbar' #373, and Application-title-bar, plasmusic undefined wuth Auto installing #259 from recurring in the stable branch.

Codebase

• Remove with lib; at the Beginning of Files: Avoid using with lib; at the start of files to improve code clarity, especially in environments lacking tree-sitter or a robust LSP. Removing these statements will make scoping clearer and align with the best practices outlined in Nix documentation.

New features

• Implement plasma-manager CLI Interface: Develop a unified CLI tool named plasma-manager to unify our scripts like rc2nix and write-config, as mentioned in Make rc2nix stable #337. This tool will serve as a single entry point for current and future scripts (e.g., kxmlgui), promoting a shared library for our scripts. The CLI will be installed by default when enabling plasma-manager, allowing users to execute commands like plasma-manager rc2nix.

[magnouvean]

These all look like very good suggestions to me. The stable release branch is the only one I'm a little unsure about since it would take quite a lot of work, but I can see the issue we have without support for this as well, so I'd be OK with it :)

[HeitorAugustoLN]

These all look like very good suggestions to me. The stable release branch is the only one I'm a little unsure about since it would take quite a lot of work, but I can see the issue we have without support for this as well, so I'd be OK with it :)

Thanks for the feedback! I get your hesitation about the stable release branch, it does sound like a lot of work. But I don’t think it'll be too crazy. The biggest part is just checking if changes are backward-compatible, and after that, we can just use the backport workflow I set up in #383 to handle the rest. Shouldn’t be too bad! 😄

[SigmaSquadron]

Adopt Conventional Commits: Transition to using conventional commit messages in the format: [optional component]: .

If I may provide my two cents here: I really dislike the standard "conventional commit" messages which include the type. Often, commits won't necessarily conform to a specific category, and repos using conventional commits often end up just having chores and feats everywhere, even for things like refactors or releases, which does nothing but clutter the git history.

Since this is a Nix project, why not adapt the Nixpkgs commit conventions?

[HeitorAugustoLN]

If I may provide my two cents here: I really dislike the standard "conventional commit" messages which include the type. Often, commits won't necessarily conform to a specific category, and repos using conventional commits often end up just having chores and feats everywhere, even for things like refactors or releases, which does nothing but clutter the git history.

Since this is a Nix project, why not adapt the Nixpkgs commit conventions?

Nixpkgs commit convention would also be good. But it wouldn't really help that much with versioning, and I really like the type in conventional commits. And it wouldn't be generally a problem here, because most of the commits are new features or fixes. But nixpkgs commit convention would not be a bad idea also.

[HeitorAugustoLN]

Well, I've been trying to work on the CLI, but the build systems for python are not easy to work with. I've been tempted to rewrite the scripts into a rust program, since I recently worked on cosmic-ctl. And it is was so easy. I will probably also include some other features such as configurations without groups (#415 & #17) for both write-config and rc2nix. In general, I am aiming at making our tools better, but this might take some time.

[magnouvean]

That's really cool @HeitorAugustoLN! I could get behind a rust-program for writing the files for that matter, though if it becomes rather advanced I think it could make sense to have as a separate repo.

I have previously though a bit about moving some more of the logic in plasma-manager away from nix itself and more to the config-writing script and just use that interface for plasma-manager if possible, since that would make the work we've done available to people in the whole linux-world, and not just the ones using nix (one of my biggest complaints about KDE, which I have seen a lot of other people mention as well is the lack of proper config-files). Versioning would also probably be easier.

With that said though, that would maybe be a lot of work, so I'm not sure if it's going to happen (maybe I'll explore the option when I get some more time again to work on the project). For such a task though I think rust would work well, as it's proven to be great for CLI programs (and I've always wanted to use rust for some bigger project).