I am on a Mac with M1 chip and I have a problem with my VScode and python. It stays stuck on the ZSH shell even when I type the command to switch to bash (chsh -s /bin/bash). Lets say I run a simple code:
import cowsay
import sys
if len(sys.argv) == 2:
cowsay.cow("Hello, " + sys.argv[1])
I am supposed to be able to type my name in the shell after my python file name and it should print the cow saying Hello, Noah.
When I do so ((base) noahhaitas#Noahs-Mac-mini ~ % python3 itunes.py Noah Haitas), this is what I get as a message in my shell:
(base) noahhaitas#Noahs-Mac-mini ~ % python3 itunes.py Noah Haitas
/Library/Frameworks/Python.framework/Versions/3.10/bin/python3: can't open file '/Users/noahhaitas/itunes.py': [Errno 2] No such file or directory
I am trying to figure out how I can switch fully to bash and have the $ in front instead of seeing the % of ZSH.
What can be done as this is frustrating and I looked everywhere online and tried pretty much every solution.
Vscode is just an editor, and the system terminal is still applied.
Use the following command in the terminal to switch bash and restart the terminal:
chsh -s /bin/bash
At the same time, you can also set manually in the vscode terminal. Take Windows as an example:
Read the docs for more details about terminal settings.
By the way, there is an error when you run the file. It seems that the python file is not run in the correct directory.
how would I run python script on startup (on Raspberrypi 4B, Raspi_os 64bit) within an python(3.9) environment?
I tried to just add
source envname/bin/activate to launcher.sh
my launcher file looks like this:
cd /home/pi/thefolder
PYTHONPATH=/home/pi/.local/lib/python3.9/site-package
source envname/bin/activate
pyhton3 /home/pi/thefolder/run.py
Apparently the python3 command is not run in the env as I get an ModuleNotFoundError for Pandas. Which is installed in the env.
EDIT1:
if I just create a new shell script with only
source envname/bin/activate
echo Hi Stackoverflow
running after chmod with sh test.sh I get the return
> test.sh 1: source: not found
> Hi Stackoverflow
while I can activate the env in the terminal
EDIT2:
Apparently Ubuntu bin/dash ist used and not bin/sh. Here is post about it
Now I have to checkout how to change it
Edit3:
using :
. envname/bin/activate
echo Hi Stackoverflow
instead of
source envname/bin/activate
echo Hi Stackoverflow
seems to work. Testing in progress
---Final Edit:---
Yes it works. But important, it apparently has to be in the first line otherwise the file envname cannot be found
Using
. envname/bin/activate
echo Hi Stackoverflow
instead of
source envname/bin/activate
echo Hi Stackoverflow
Works. As Ubuntu uses /bin/bash instead of /bin/sh
Apparently the . envname/bin/activate has to be the first command
I have latest GVim (v8.2) 64-bit and Miniconda Python 3.8.5 64-bit installed on Windows 10. I am working in the virtual environment da38 and included the following two lines in my $HOME\_vimrc file to point to the correct python interpreter and libraries for this environment:
set pythonthreehome=$HOME\miniconda3\envs\da38
set pythonthreedll=$HOME\miniconda3\envs\da38\python38.dll
Both :echo has('python3') and :echo has('python3_dynamic') return 1. I have installed Vim plugin dense-analysis/ale for python linting, and installed flake8 and black packages in da38 using conda install flake8 black. And I added the following lines in $HOME\_vimrc to configure this plugin:
let g:ale_linters = {'python': ['flake8']}
let g:ale_fixers = {'*': [], 'python': ['black']}
let g:ale_fix_on_save = 1
But the plugin does not show any error on a python file that has many by design: running flake8 test.py on command prompt returns a lot of errors. :ALEInfo repeats these two lines several times:
(executable check - failure) flake8
(finished - exit code 1) 'cmd /s/c "cd /d "C:\Users\Admin\Desktop" && black - < C:\Users\Admin\AppData\Local\Temp\VIBA694.tmp\test.py"'
I am wondering if somehow the correct python path is not being passed to Vim, but cannot figure out what else to do. Any help is much appreciated.
Thanks
UPDATE:
I think I narrowed down the problem. Linter plugin fails when I open test.py with vim from the desktop icon, but works if I first activate the virtual environment with conda activate da38 and then start vim on command prompt. I guess the desktop vim does not see the virtual environment, where the two packages flake8 and black are installed. So I believe the problem is how to add the appropriate python environment to the desktop vim. I should add the vim-conda plugin did not help.
UPDATE #2:
I managed to get vim-conda plugin working with gvim, and now the linter plugin works as expected.
UPDATE #3:
One can avoid using a plugin and instead hard-code the environment path in _vimrc (for windows):
let venv = 'da38'
let mypath = 'C:\Users\Admin\miniconda3\envs\' . venv . ';'
\ . 'C:\Users\Admin\miniconda3\envs\' . venv . '\Scripts;'
\ . 'C:\Users\Admin\miniconda3\envs\' . venv . '\Library\bin;'
let $PATH = mypath . $PATH
This code sticks the env path in front of default $PATH.
Trying to send some output to Slack using cron on an instance of GCP Compute Engine running Linux Ubuntu 18.04.2 LTS.
Output is generated by python script.
Python script is usually run using conda activate my_env and python my_script.py
I have made the bash file executable by doing chmod +x my_script.bash
Here is content of bash file:
#!/bin/bash
source /home/user/miniconda3/bin/activate
conda activate my_env
python /home/user/folder/cron/reports.py -r check_stocks
I would expect adding the following line to crontab -e:
00 21 * * * cd /home/user/folder/cron/ && /bin/bash my_script.bash would give me the same results.
I run cd /home/user/folder/cron/ && /bin/bash my_script.bash in my shell and the script runs fine.
Make your .py file exacutable too (chmod +x file.py) - otherwise it won't work.
You can find similar issue resolved here.
I had a similar issue and I gave up activating the conda environment and instead called directly the python bin in the miniconda environment folder, like this:
00 21 * * * /home/myuser/miniconda3/envs/my_env/bin/python /home/user/folder/cron/reports.py
I don't think this is the recommended solution, especially if you have a complex project with dependencies and you are importing a lot of modules, but for my simple script it solved the problem.
So, once again, I make a nice python program which makes my life ever the more easier and saves a lot of time. Ofcourse, this involves a virtualenv, made with the mkvirtualenv function of virtualenvwrapper. The project has a requirements.txt file with a few required libraries (requests too :D) and the program won't run without these libraries.
I am trying to add a bin/run-app executable shell script which would be in my path (symlink actually). Now, inside this script, I need to switch to the virtualenv before I can run this program. So I put this in
#!/bin/bash
# cd into the project directory
workon "$(cat .venv)"
python main.py
A file .venv contains the virtualenv name. But when I run this script, I get workon: command not found error.
Of course, I have the virtualenvwrapper.sh sourced in my bashrc but it doesn't seem to be available in this shell script.
So, how can I access those virtualenvwrapper functions here? Or am I doing this the wrong way? How do you launch your python tools, each of which has its own virtualenv!?
Just source the virtualenvwrapper.sh script in your script to import the virtualenvwrapper's functions. You should then be able to use the workon function in your script.
And maybe better, you could create a shell script (you could name it venv-run.sh for example) to run any Python script into a given virtualenv, and place it in /usr/bin, /usr/local/bin, or any directory which is in your PATH.
Such a script could look like this:
#!/bin/sh
# if virtualenvwrapper.sh is in your PATH (i.e. installed with pip)
source `which virtualenvwrapper.sh`
#source /path/to/virtualenvwrapper.sh # if it's not in your PATH
workon $1
python $2
deactivate
And could be used simply like venv-run.sh my_virtualenv /path/to/script.py
I can't find the way to trigger the commands of virtualenvwrapper in shell. But this trick can help: assume your env. name is myenv, then put following lines at the beginning of scripts:
ENV=myenv
source $WORKON_HOME/$ENV/bin/activate
This is a super old thread and I had a similar issue. I started digging for a simpler solution out of curiousity.
gnome-terminal --working-directory='/home/exact/path/here' --tab --title="API" -- bash -ci "workon aaapi && python manage.py runserver 8001; exec bash;"
The --workingdirectory forces the tab to open there by default under the hood and the -ci forces it to work like an interactive interface, which gets around the issues with the venvwrapper not functioning as expected.
You can run as many of these in sequence. It will open tabs, give them an alias, and run the script you want.
Personally I dropped an alias into my bashrc to just do this when I type startdev in my terminal.
I like this because its easy, simple to replicate, flexible, and doesn't require any fiddling with variables and whatnot.
It's a known issue. As a workaround, you can make the content of the script a function and place it in either ~/.bashrc or ~/.profile
function run-app() {
workon "$(cat .venv)"
python main.py
}
If your Python script requires a particular virtualenv then put/install it in virtualenv's bin directory. If you need access to that script outside of the environment then you could make a symlink.
main.py from virtualenv's bin:
#!/path/to/virtualenv/bin/python
import yourmodule
if __name__=="__main__":
yourmodule.main()
Symlink in your PATH:
pymain -> /path/to/virtualenv/bin/main.py
In bin/run-app:
#!/bin/sh
# cd into the project directory
pymain arg1 arg2 ...
Apparently, I was doing this the wrong way. Instead of saving the virtualenv's name in the .venv file, I should be putting the virtualenv's directory path.
(cdvirtualenv && pwd) > .venv
and in the bin/run-app, I put
source "$(cat .venv)/bin/activate"
python main.py
And yay!
add these lines to your .bashrc or .bash_profile
export WORKON_HOME=~/Envs
source /usr/local/bin/virtualenvwrapper.sh
and reopen your terminal and try
You can also call the virtualenv's python executable directly. First find the path to the executable:
$ workon myenv
$ which python
/path/to/virtualenv/myenv/bin/python
Then call from your shell script:
#!/bin/bash
/path/to/virtualenv/myenv/bin/python myscript.py