DEV Community

Kannav Sethi
Kannav Sethi

Posted on

A Practical Approach to TOML Files and Remote Branch Management

This week I had the opportunity to work on TOML Config files and to review a change made on my repository by pulling the changes locally from a fork of my project

What are TOML Files

TOML (Tom's Obvious Minimal Language) is a configuration file format that uses a simple key-value pair to define the config variables to be used in a program

a TOML file might look like this

[dependencies]
requests = ">=2.25.0"
flask = { version = "2.0.1", optional = true }


[database]
type = "postgres"
host = "localhost"
port = 5432
username = "admin"
password = "password123"

[database.settings]
pool_size = 5
timeout = 30

Enter fullscreen mode Exit fullscreen mode

The way these files work is by using a parser to parse the content from the TOML file and then use the variables in the program

The reason that it is preferred over JSON or YAML is because of it is easy to be written and comprehended by a human and it succeeds at configuration management.

My Use Case Of TOML

This week I had the opportunity to work on a great project, Addcom, This is a CLI tool that takes in sample files and generate inline comments for the files, it utilises Groq API to generate the comments for the file

Now when calling the CLI tool, the user can define some optional arguments that can be used while making an API request to Groq, which are the following

  • model - the model to be used for Groq API
  • stream - this is a boolean value that will specify if the output should be streamed or not
  • api_key- the API key to be used for the Groq
  • context- path to the file that would provide context to the LLM

Now it would be really frustrating for the user to specify the same argument value again and again in the CLI tool, to avoid this I implemented a TOML file that would contain all of the config settings and values to be used so that rather than specifying the config settings repeatedly, the program can just look into the TOML file and apply the relevant settings.

The logic flow for the program would be as follows

1) The CLI tool will be called in the terminal
2) If no arguments are there, the variables from the TOML file will be used
3) If the variables in the TOML file are wrong then they will not be used, the program will exit with error code 0
4) If the user provides the command line arguments as well along with the TOML file, the command line arguments would be used
5) The operation is performed with the correct arguments

To find a descriptive overview of the issue that I raised in the repo, click here

moreover to find the relevant PR for the same click here

Working with Git Remotes

Till now, whenever I had to merge a PR, I had to do it through Github, but this time around I found a really exciting way to do the same locally

I had someone working on implementing a feature for my CLI tool, the same person created a fork of my codebase and started implementing the feature, once it was implemented , they pushed the code to the their topic-branch on their fork.

Now before I can approve the changes , I had to review the code changes and make sure they were working and didn't cause any unprecedented issues

To achieve this , I implemented the following steps

git remote add <user_name> <user_name/fork>

Enter fullscreen mode Exit fullscreen mode

the above command would add a remote connection to a fork of my codebase

git fetch <user_name/fork>
Enter fullscreen mode Exit fullscreen mode

this would fetch all of the new branches from the remote repository and update my local .git folder

git checkout -b review-change <user_name/fork>
Enter fullscreen mode Exit fullscreen mode

this would create a new branch called as review-change that would be built on top of the topic-branch, so as to be able to review the changes made by the person

once I have reviewed the changes I will do the following

git checkout main
git merge review-change
Enter fullscreen mode Exit fullscreen mode

this would perform a fast-forward merge as no changes had been made on my local main

git push origin main
Enter fullscreen mode Exit fullscreen mode

this command would be performed to push the merged changes to my remote repository which would then automatically close the PR that the person had opened.

Conclusion

This week, I gained valuable experience working with TOML configuration files and managing Git workflows for code contributions. Implementing TOML allowed users to define reusable configuration settings for the Addcom project, simplifying the CLI tool's usage and enhancing user convenience. Additionally, I learned how to review and merge changes from a contributor's fork locally by adding their remote repository, fetching the changes, and performing a fast-forward merge.

Top comments (0)