For this weeks task, we were supposed to contribute to someone else's repository. This week my partner was @sych_andrii aka Andrii.
My contribution
I was supposed to implement a flag -u or --token-usage, when used would display Chat completion token count. So I filed a issue on his repo. After which I got busy implementing the feature. It was a lot more work than I expected.
Since this tool is written in python using LangChain. The LangChain framework has a lot of feature leading to a lot abstraction. One of the feature was chaining where prompt, model and parser can be linked like a chain and when the chain is invoked, the output would be automatically passed from one to another and user will get the output from the parser.
Easy implementation would be to break the chain and get the output from the model and then separately pass it to the parser manually. I did not want to break this chain and pipe so I was digging through the docs to find any reference. After a while I reached out to Andrii to get some guidance on which docs he used and what my approach was. After a while he gave me docs to RunnableLambda. This enabled me to insert a Lambda function in between the pipe.
So I implemented the solution and made a PR. After which Andrii requested changes to the current implementation where instead of conditional RunnableLambda and empty Lambda insertion he wanted RunnablePassthrough to mark function as simply passing value. I also updated the docs at some point. So I implemented that and my changes were accepted. So in short, I made one method to display the token info and I added one additional conditional pipe.
The process was pretty standard, where I made an initial PR and we had conversation and I implemented a solution and some more changes were requested. The change was pretty minimal and I was consistent with how the existing code was written. Next time for my own sanity, I would choose a project where I'm more comfortable with the the language.
Feature for my Tool
Andrii implemented similar feature on my repo as well. He filed a issue. The PR was pretty simple and concise. My only feedback was to keep the options alphabetical on the source code and use more meaning full variable names instead of one letter ones. Since I often find myself very confused reading a code after it's been a while, and I'd rather have descriptive and long variable names that are easier to understand than short variable names that look clean but eventually becomes confusing. So, after a PR was made I left comments in my code review. And after the fixes were made and I was satisfied I merged the PR.
Conclusion
It was a pretty good experience. When working in someone else's PR you have to conform to their coding style which can be very different than yours. So it was a good first experience to get prepared for future contributions to other's repos.
Top comments (0)