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: 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.

