Name: Aadi Bajpai
Email: [email protected]
University: Vanderbilt University (probably), Nashville, TN
Potential Mentor(s): Willem Van Iseghem, ...
The SwagLyrics suite of repositories is an ecosystem of backend applications, a couple of python libraries, a chrome web extension (soon!) and even a discord bot. Over the course of this summer, we aim to work individually on these components as well as on how they interact together. The ultimate idea is to create a noops infrastructure, that is, a system that maintains itself and does not require any essential input from an actual human being, thus ensuring that such a proposal can never be created again (lol). Overall, the goal is to lend a degree of finality to the project and working on essential non-essential areas that cannot be simply ignored, as they have been until now. In essence, this proposal can be considered similar to the CCExtractor Sample Platform proposal last year.
To give better insights, there is currently no formal logging setup, no complete test coverage for the backend, resolving issues isn't as automated as I'd like it to be and diagnosing every issue by opening up raw logs is not very productive. The current process of supporting more songs leaves something to be desired even though we have a database configured for this purpose.
Other than these, there are also a few features to be worked upon that require time, which will be elaborated upon in the later stages of this proposal.
SwagLyrics for Spotify is the primary project ("swaglyrics") that contains both, an interface for fetching lyrics given a song and artist, as well as the application to continually fetch lyrics for the currently playing song on Spotify.
SwSpotify is the cross-platform python library that fetches the current track info from Spotify. This is used in swaglyrics but also by other developers in their application. The new Chrome Extension aims to add support for the Spotify Web Player, thus extending SwSpotify to work anywhere Spotify works.
swaglyrics-backend is the backend Flask application hosted on https://api.swaglyrics.dev which provides endpoints that the main application communicates with to sometimes better support lyrics for tracks that cannot be directly resolved by the main application but also to create and manage issues on the GitHub issue tracker to identify potential improvements. The backend also takes care of its own deployments from GitHub as well as sending relevant notifications to the Discord server via webhooks.
"stripper" refers to the string resolved when given a song, artist pair, generally after stripping away punctuation and other modifications. For example, the stripper for
River (feat. Ed Sheeran) by
Eminem would be
eminem-river which when appended to the genius.com url would give us the lyrics page for that song.
loggingto configure a proper logging implementation on the backend.
pytestwhich currently sits at a mere 50% with most of the endpoints untested.
!add stripper abc-xyzwhich automatically updates the backend database and closes the issue or just
!closefor issues that are not fixable by us which simply closes the issue.
$slthen it will fetch lyrics for the currently playing track, or you can specify song and artist like
$sl Hello Adele.
discord.pywhich is used to communicate with Discord. Also, a way to stop the mode will be figured out so we don't have to be dependent upon the user to end it manually.
These should also serve as buffer in case there is extra time in any of the phases.
Adding type hints
Adding support for Bollywood songs
Using instrumentalness while deciding whether to make issues
Adding request timeouts to all requests
Moving away from global variables
Figure out more trivial cases for whom issues should not be created
Adding a proper update text sort of thing whenever there is a new release that tells why you should update
Checking for updates just once a day instead of every time the application is run
Working on the flow and content of the Discord bot commands
$has a high possibility of being used by other bots too
Addressing a recent bug that has started appearing when lyrics aren't fetched the first time around but it works when you do it again.
(Optional) Renaming the stripper function to something more family friendly
Other stuff that will eventually pop up over the course of 3 months when delving into the code
I anticipate that adding the logger and then configuring notifications and writing unit tests can easily take more time than anticipated, especially with edge cases. Hence, I haven't added another Major Track for this phase other than the DDoS flaw since that is a priority.
This is pretty solid, since the current issue handling infrastructure is low-key convoluted and we'll be using the new logs from the previous phase in issue handling here. Also, the first minor track here is less major than major tracks but more major than other minor tracks.
This phase deals with the creation of new stuff, hence I expect the major tracks to be slightly more time consuming as I would be starting from scratch. A buffer period here is equally important in case more time is needed to add finishing touches.
Yes true, it's not one of those projects that's going to do something novel and play with some cool new technology but I feel it's some legit work that will stick around for a long time. Fixing a 1000 small problems over the next 4-5 months in something that's being used by a lot of people everyday is quite valuable for me than to spend time on a project that wouldn't see any sunshine once the summer is over.
Since I personally use the project I can firsthand appreciate the value that will be added not only as a maintainer but also as a user. Which is why I humbly hope this proposal gets a slot :)
I am Aadi, an incoming freshman at Vanderbilt to study computer science with possibly some other things. I have been deeply involved with open source software since 2017 when I chose to compete in Google Code-in with an organization called CCExtractor Development. Since then I've been a Google Code-in Grand Prize Winner, 2x mentor and even a Google Summer of Code mentor last year!
Programming-wise, I generally work with Python and have been known to work with C++ sometimes. If needed, I have no doubt I can pick up whatever is required quite smoothly.
Other than programming, I've found an interest in speaking at conferences and travelling when I can. Academically, I'm interested in music tech as well as privacy and anonymity research which I got involved in a bit last year.
Through Google Summer of Code, I hope to acquire professional skills and knowledge while working on a familiar project which would help me prepare myself not just for college but also the real world of software development as I move into the next phase of my education.