Upgrading Python in a Virtual Environment

I have been wanting to use my Heroku account for a while with something a little more interesting than a Jupiter Notebook.

I was hoping to try and do something with Django … but there’s a lot to using Django. I have some interesting things I’m doing on my local machine, but it’s not quite ready yet.

I had googled to find other Python Web frameworks and saw that Bottle was an even more light weight framework than Flask, so I thought, hey, maybe I can do something with that.

I found this tutorial on how to do something relatively simple with Bottle and deploying to Heroku. Just what I wanted!

I got through to the end of the tutorial and deployed to Heroku. The terminal output from the Heroku command indicated that a newer version of Python (3.7.3) was available than the one I was on (3.7.1).

I figured it would be easy enough to upgrade to the newest version of Python on my Mac because I had done it before.

I don’t know why I thought the virtual environment would be different than the local install of Python 3 but it turns out they are more tightly coupled than I thought.

Upgrading to 3.7.3 broke the virtual environment I had in PyCharm. I did a bit a googling to see how to upgrade a virtual environment and found nothing. Like literally nothing.

It was … disheartening. But after a good night’s sleep I had a thought! What if I just delete the virtual environment directory and then recreated it.

I ran this command to remove the virtual environment:

rm -R venv

Then created a virtual environment in PyCharm and now I have 3.7.3 in my virtual environment.

I had to make some changes to the files for deployment to Heroku, but that’s all covered in the tutorial mentioned above.

Sometimes the answer is to just restart it … and sometimes the answer is delete it and start over.


I was listening to an episode of Python Bytes and heard Michael Kennedy (of Talk Python to Me fame) describing basically the same issue I had. Turns out, he solved it the same way I did. Nice to know i’m In good company.

Did you try restarting it?

The number of times an issue is resolved with a simple reboot is amazing. It’s why when you call tech support (for anything) it’s always the first thing they ask you.

Even with my experience in tech I can forget this one little trick when troubleshooting my own stuff. I don’t have a tech support line to call so I have to google, and google and google, and since the assumption is that I’ve already rebooted, it’s not a standard answer that’s put out there. (I mean, of course I rebooted to see if that fixed the problem).

I’ve written before about my ITFDB and the announcement from Vin Scully “It’s Time for Dodger Baseball!”. With the start of the 2019 season the mp3 stopped playing.

I tried all sorts of fixes. I made sure the Pi was up to date with apt-get update and apt-get upgrade. I thought maybe the issue was due to the version of Python running on the Pi (3.4.2). I thought maybe the mp3 had become corrupt and tried to regenerate it.

None of these things worked. Finally I found this post and the answer was so obvious. To quote the answer:

Have you tried rebooting?

It’s a total shot in the dark, but I just transitioned from XBMC to omxplayer and lost sound. What I did:

apt-get remove xbmc

apt-get autoremove

apt-get update

apt-get upgrade

After that I lost sound. 10 minutes of frustration later I rebooted and everything worked again.

It wasn’t exactly my problem, but upon seeing it I decided “What the hell?” And you know what, it totally worked.

I wish I would have checked to see when the last time a reboot had occurred, but it didn’t occur to me until I started writing this post. Oh well … it doesn’t really matter because it works now.