Working with Config Files

Can't believe it's almost half of the semester gone! This week, our task was to add a TOML config file to a partner's repo, which looks something like this:

[output]
display_token = false
stream_response = false

[api]
api_key = "..."
base_url = "..."

Once again, I teamed up with Amir - The true warrior who's never been afraid of Rust since day one! We had a very eventful week: lots of fun, lots of frustration, lots of back and forth communication. But overall, it was a blast!

Working on Amir's repo

Honestly, this went a lot easier than I thought. We had a bit of a chat prior to this where we walked each other through some new changes in our repos. Turned out it was all we needed for a smooth sail. When I started the actual work, it was pretty much a linear process: I filed the issue. He assigned me the task. I implemented the feature and filed the PR. He reviewed the code. And the code was merged.

I did remember to ask him about the file structure, since I was a bit confused the last time we collaborated. For the implementation I went with night-config. This library provides everything I needed - It supports toml files and can read them into config options which I could directly work with. Since his project only deals with command line arguments and config files, there's no confusion in terms of priority either: Always prefer arguments. If they don't exist, fall back to the config file.

Working with Amir on my repo

Now this is the fun part. This was a bigger feature than anything we've done before, so I expected problems. We actually ran into quite a few.

The first one was with environment variables. My project already supported environment variables for certain specifications, as well as command line arguments. We were bring a third option to the mix - the config file. Where would this fit in? I thought about it for a while and asked in his issue as well. I felt like I couldn't really make a decision until I see the implementation, so I asked him to comment out the lines related to environment variables for now, and focus on just the config file.

Another problem was that I merged some other branches to main during his development, and I went on his branch and merged those new changes there as well. However, he wasn't very informed of this and did a force push, which really messed up the commit history. Fortunately, he figured out a solution to reset locally and force push it again. Crisis averted!

Then we went on a few rounds of code reviews and series of back and forth comments. Some are about design choices, others about code logic, bugs or simple oversights. For example, I asked him to put the config file at a specific location, and pointed out a formatting issue with the generated config file. He was incredibly patient and flexible throughout the whole process and I truly respect that - Again, I couldn't have asked for a better partner!

On the git side, I created a remote to his fork on my local repo, and set up a tracking branch. I was able to pull in all his commits on this branch and test them on the go. This had made the review process a lot faster!

Eventually, we sorted out everything. We ended up with a pretty satisfying result and a quite lengthy PR