Why does heroku local:run wants to use the global python installation instead of the currently activated virtual env?

Question

Using Heroku to deploy our Django application, everything seems to work by the spec, except the heroku local:run command.

We oftentimes need to run commands through Django's manage.py file. Running them on the remote, as one-off dynos, works flawlessly. To run them locally, we try:

heroku local:run python manage.py the_command

Which fails, despite the fact that the current virtual env contains a Django installation, with

 ImportError: No module named django.core.management

 Diagnostic through the python path

Then heroku local:run which python returns:

 /usr/local/bin/python

Whereas which python returns:

 /Users/myusername/MyProject/venv/bin/python #the correct value

---

• Is this a bug in Heroku local:run ? Or are we missunderstanding its expected behaviour ?
• And more importantly: is there a way to have heroku local:run use the currently installed virtual env ?

Answer 1

After contacting Heroku's support, we understood the problem.

The support confirmed that heroku local:run should as expected use the currently active virtual env.

The problem is a local configuration problem, due to our .bashrc content: heroku local:run sources .bashrc (and in our case, this was prepending $PATH with the path to the global Python installation, making it found before the virtual env's). On the other hand, heroku local does not source this file. To quote the last message from their support:

heroku local:run runs the command using bash in interactive mode, which does read your profile, vs heroku local (aliased to heroku local:start) which does not run in interactive mode.

Answer 2

To add to Ad N's answer. The reason it absolutely insisted on using system Python instead of the virtual environment that it was used from is as follows.

Heroku local:run sources .bashrc which includes a user's PATH and any additions to the default PATH. This includes the location of system Python, but not necessarily any additional Python interpreters. It will use whichever Python interpreter is found first, which should rightly be the system Python (otherwise very import things like init and package management don't work correctly, or at all)

The way around this is instead of running it as heroku local:run which sources .bashrc and includes the system Python is to run it as heroku local so that it uses whatever is active in the virtual environment.