Introduction
Every project comes with its own set of challenges. These range from technical to personal in nature and with varying degrees of difficulty in their resolution. These challenges provide the opportunity to flex your problem-solving skills and often can lead to greater understanding of the people and tools that you are using.
Unwinding Dependencies
Perhaps the greatest challenge that I’ve faced in our project was very recent and allowed me to gain a greater understanding of some of the fundamental tools that come with Python out-of-the-box. Our project is focused on developing a web application that allows its users to create algorithmic stock trading strategies. This project relies heavily on historical stock market data, for which we use the yfinance Python library.
Two weeks ago (the week of 2/17/2025), Yahoo Finance changed their API which broke most versions of yfinance. For most stock tickers, yfinance would return zero results with an error message stating that it was possible the stock had been delisted. These changes were far reaching, with a number of posts from StackOverflow, Reddit, GitHub, and niche stock trading forums all having the same issues. Our project was at a bit of standstill – we couldn’t perform much testing without the data. Our frontend team was effectively the only functional area that could still perform work and verify its integrity.
The same day we found the issue, yfinance released an update that corrected the issues. It turns out that Yahoo Finance had changed their API which led to the downstream issues in the yfinance library. The solution was to simply upgrade your yfinance version to the most recent release. This notion is great in theory, but our project is the culmination of several years of work and leverages some dependencies that aren’t necessarily deprecated, but also aren’t the most recent versions. With this in mind I began working on a solution.
The first step was to verify that the solution would work – I stood up a test project and installed the latest version in a virtual environment and attempted to fetch data. When this worked, I tried the simplest form of troubleshooting and simply upgraded the version in our project’s requirements.txt file and reinstalled the requirements in my virtual environment for the project. While I hoped it would be, the solution wasn’t this simple. I was getting a different error message though, so I knew I was making progress.
The next step was to resolve an error that was occurring regarding our inputs to the optimization component of our project. The error stated that strings were being passed to the optimizer and that they couldn’t be resolved. This hadn’t been an issue in the past, so there must have been some explicit type-casting that was removed from the yfinance library. Explicitly casting our user input to the type that the library expected solved that error message. However, this wasn’t the end of the climb. This yielded a new error message.
The next issue that arose was a date format error that occurred in an indirect dependency to our backtester. Older versions allowed for date-formatted strings to be passed to our backtester, but newer versions moved away from this and required explicit dates to be passed. However, version 2.4.3 still supported the methods that our project uses. Rolling this dependency back to this version cleared the error message and allowed us to start our controller and frontend simultaneously.
Basic Python
While none of this required any high-speed Python, it did require some intense problem solving sessions as many of the error messages had traces exceeding 100 lines. In addition, it got me far more familiar with Python’s virtual environments and experimenting with varying versions of the Python Interpreter – something that I hadn’t dug into much in the past.
Uninstalling and reinstalling virtual environments over and over was tedious, but it allowed me to understand their benefits. I could containerize my changes to a new virtual environment, test them, and when they didn’t work I could delete the virtual environment, rollback my changes, and try something new. All of this done without affecting my computer’s base Python environment.
This experience also got me familiar with having several versions of Python installed on my computer and setting my virtual environment to run with an interpreter that was different than the one I use for my personal projects. I was able to test my changes with Python 3.9-3.13 while still being able to do other work with Python 3.13.
Conclusion
While challenges aren’t always fun – especially when they include unwinding a web of dependencies – they do provide unique opportunities to dive into the “dark corners” of our skills. These dark corners can be areas we haven’t had to explore previously, areas that we’ve been avoiding, or areas we simply haven’t had time to explore in our skillset. However, when problems like these arise, they facilitate a need to explore them which can be one of the greatest motivators for knowledge gain. Unwinding the challenges that we faced with the yfinance library did just that for me with respect to the Python Interpreter and virtual environments.