contributing

Hi, welcome! Thanks for wanting to help out!

To contribute just fork this repo and send me a pull request!

I'm trying to keep things as tidy as possible for a long running project. Any new commands should be placed in the appropriate .rs file.

Core design requirements for Commands

This tool is multi-threaded to an extent. Some commands run long-running routines that would be bad to block execution to wait for them to be done. For such routines a new thread is created and the join handle is returned to the cli function. The cli function then keeps a list of threads created so that it can .join() them at shutdown.

The general execution flow is the cli() function prompts the user for input. It then does a quick match statement to see if its a "special" command or a normal one. In this case a "special" command is one that is run against the tool, and not the project. If the command doesn't match any "special" commands then it passes it to the run_cmd() function, saving any return as an Option<JoinHandle<()>> type.

The run_cmd() function then uses a larger match statement to determine what command to run.

adding new commands

To add your command to this simply create a new entry in the match statement in the following format:

For commands that don't need to spawn a new thread: "full command name" | alias1 | alias2 | .. => {corresponding_file.rs::function_name(parameters); return None},

For commands that do need to spawn a new thread: "full command name" | alias1 | alias2 | .. => {let handle_name = corresponding_file.rs::function_name(parameters); return handle_name},

This will pass the thread handle to the cli() function to track so it can join() them at shutdown.

Then create a similar entry in the help() function's help_cmd match statement. The help function should include the command name, any aliases for the command, and a brief description of what the command does. "full command name" | alias1 | alias2 | .. => {println!("Command:Full command name\nAliases:alias1, alias2, ..\n\nThis command does things and stuff to the current active project.

Available information for commands.

the Project struct contains the following data:

• customer: String (customer name)
• project_name: String (project name)
• notes_folder: PathBuf (path buffer of the notes folder for the project)
• files_folder: PathBuf (path buffer of the files folder for the project)
• active: bool (whether it is the active project or not)
• boxname: String (the project's custom distrobox name)
• stage: String (the stage the project is in, upcoming or current)
• id: i32 (the id of the project that is calculated at run time)

The currently active project is tracked via the active_project variable in the cli() function. If the command you're writing only needs to read data from the project struct you an access it with a reference (&active_project). The list of all projects is tracked as a Vec variable named projects, you can pass this to your function if your command needs to interact with more then just the active project.

Generally I would prefer that the projects list be cloned then modified and saved to the projects.conf file instead of trying to modify the projects them selves.

adding a new .rs file

Once you make the .rs file you want to add, be sure to add it to the code by adding a mod statement in main.rs. keep it within the block of other mod statements.

Once you've added the mod statement use it in the cli.rs file by adding a use crate statement, it should be put in the block of other use crate statements.