The “Contributor’s Story” series is intended to provide a face and voice to our major open source contributors and community members, an overview of the projects they are working on, and the successes and challenges contributors face when developing.
In this blog post, we will be talking to Grace Gao, a Pysa contributor working on a Pysa VSCode plugin through the Major League Hacking (MLH) Fellowship.
“The MLH Fellowship opened up a lot of new possibilities for growth and I’m really grateful to have been part of a community that’s always inspiring me to ‘level up.’”
Hi, I’m Grace (she/her) - here’s a bit about me:
I joined the MLH Fellowship last fall and this is now my second term contributing as an Open Source Fellow! After graduating high school last year in the midst of a pandemic, I found I had a lot of free time to try out new coding frameworks and play with miscellaneous personal projects. When my friend first introduced me to this program, I recognized the familiar MLH logo from hackathons and it seemed like exactly what I needed to “level up” my learning approach. Despite not having much professional coding or open-source experience, I decided to give it a shot (and I’m really glad I did)!
Like most other things, the Internet taught me! When I first started using Github to collaborate on hackathon projects last year, I barely knew anything about open source. At the time, I thought it was just an upgraded version of a cloud drive. As I dove deeper into the online coding community, I found all sorts of cool projects and resources, which were great starting points for learning new technologies (code is a lot less intimidating when someone else already did most of the work). Whenever I’m stuck, Github repositories became my first resort and more often than not, I’d find solid examples to play around with.
Going into the Fellowship, I only had limited working knowledge of Github and open source, but the people around me were incredibly helpful in catching me up to speed. This was my first time contributing to projects that were maintained and used by other developers, as well as many other ‘firsts’ - my first pull request, my first issue, my first time failing integration tests. Learning to be a good open source citizen has definitely changed the way I approach coding and given me the confidence to become a more active part of this community.
Right now, I’m working on Pysa (an open source Python Static Taint Flow Analysis tool from Facebook) along with my teammates Sayd and Sarthak, our mentor Javid and the maintainer Graham. The goal for our team is to build a Pysa VSCode plugin, similar to the existing plugin for Pyre. This would include features such as syntax highlighting, right-click menus, and analyzing Pysa errors for any workspace containing .pysa files.
To get started, I went through a lot of documentation and tutorials for Pyre and Pysa to get a better understanding of the project. The links provided by Graham were especially helpful for learning about the different file formats and how they work, as well as Language Server Extensions in VSCode. Since Pysa is built on top of Pyre (Facebook’s Python type checker), the existing VSCode extension for Pyre was also a great reference point for understanding and building the new Pysa extension.
For me, a major roadblock was getting set up with Pyre onto my laptop. I initially tried to follow the installation docs, but received a lot of low-level errors that prevented me from moving forward. Reading through a similar issue on Github, it seemed that this tool was unfortunately not yet supported on my Apple M1 laptop.
As a workaround, Graham suggested using a Docker container. I ran a Debian image and followed the docs to build from the source, which involved a lot of trial and error, as well as searching for error messages. A couple of dependencies and steps were missing from the docs, but I managed to fill in the blanks and get it up and running, with the help of my team. Since the other fellows had also faced similar challenges building from source, I created a Dockerfile and documented my setup. Afterward, I made a pull request to the project so that future contributors would have an alternative way to get set up quickly using Docker.
So far, my team has completed the first couple of steps to set up the VSCode extension and create the language server. I joined this project a little later in the term, so I’ve mostly been working to catch up to speed and contribute to the Docker image. Currently, we’re working on implementing the plugin features, and I’m trying to set up syntax highlighting for taint.config and .pysa files. To do this, I’m hoping to use a Python syntax highlighter and possibly make some modifications (eg. make the fully qualified function name as a normal function name).
Broadly speaking, I’ve learned that picking up new things is not as daunting as it seems. Before this, I didn’t really know where to start with open source or development frameworks and it was intimidating to hear so many unfamiliar technical terms being thrown around casually. Looking back, I think it was mostly a mental block that quickly dissipated when I started working on my team’s projects. Overall, I’m glad that the Fellowship created a welcoming environment that’s given me the confidence to tackle future challenges and get started with contributing.
I’d say that you should feel free to create issues and add suggestions wherever you feel is right. Although it may not be exactly the issue you’re working on, you might catch a bug or notice a mistake in the docs that could save a lot of trouble for someone else. The Pysa community is very friendly and I’m sure that they would appreciate your ideas, even if your PR is not perfect and you’re unsure about the problem. Also, here’s another tip: don’t try to install Pyre on your Apple M1 when it’s not supported - consider using the new Docker image instead!