I have been having trouble using the requests package in Python 3.6.5. If I run Python 3.5, it works, but not if I run 3.6.5.
I have been trying to remedy this problem by using a virtual environment, but have not had any luck. I have created the virtualenv using this:
mkvirtualenvwrapper -p /usr/local/bin/python3.5 env_test
When I activate that environment and type python -V, it tells me it is using 3.6.5 still. When I type python3.5 -V though, it tells me it is using Python 3.5.5, and which python3.5 says it is sourced in my virtual environment folder.
I guess that virtualenv is installing other versions of Python into the environment as well, and using 3.6.5 as the default, which I don't understand why, but I need it to access python3.5 when I type python. What can I do here?
As you mentioned in your comment, you have an alias set up, where when you type python, it will automatically run python3.6.
To get past this, you have to avoid the alias. You'll have to look up alias in the man of your shell. If it's bash, you could remove the alias by typing unalias python, but chance are, this will only work in the shell you're currently in. Next time you open up a terminal or otherwise have a need to execute your .bashrc and/or .bash_profile, this will likely execute again. You could look for where your alias is set in those files, and remove that line. Or, if the alias gets set in a file outside your control, you could just add unalias ptyhon into your .bashrc.
Or, if you want to just temporarily avoid it,enclose your command in ' or ". 'python' will avoid the alias.
Once the alias is out of your way, what python will likely point you to an area in your virtual env, which should then be a symbolic link to the right version of python.
Related
I am currently trying to change my default Python version to Python3. This proves to be harder than expected.
I have already tried the following things:
I have tried to change the alias by doing alias python python3 but this seems to just change it for the running Terminal session
I have installed Python3 again with Homebrew and tried to change the directory within the zshellruncommand by defining it myself and editing it in vim
to be honest I don't really understand the process and just followed along with a tutorial but it didn't work.
I tried the command ln -s -f /opt/homebrew/bin/python3 /usr/bin/python to change the directories but it returned ln: /usr/bin/python: Operation not permitted
to deal with this problem I have already given the Terminal full access to the local harddrive but it is still not working properly
Hoping for some advise,
thanks in advance
First make sure the installed version is linked:
brew link python
then on your .bash_profile or .bashrc (.zshrc if you're using zsh) write this:
export PATH="/usr/local/opt/python#X.Y/libexec/bin:$PATH"
change X and Y to your python version
I think it's easier to just change your user shell environment instead of changing the system level environment.
vi ~/.bash
Then type
alias python=python3
Save your file by pressing Esc -> type :wq
Update your shell environment
source ~/.bash
Check your Python version.
python -V
Final result
Python 3.9.10
This works in my past few versions MacOS.
I'm teaching a beginners python class, the environment is Anaconda, VS Code and git (plus a few extras from a requirements.txt).
For the windows students this runs perfectly, however the mac students have an existing python (2.7) to contend with.
The windows students (i.e. they have a windows computer), their environment when they debug matches their console environment. However the mac students seem to be locked to their 2.7 environment.
I've tried aliasing, as suggested here and here
alias python2='python'
alias python='python3'
alias pip2='pip'
alias pip='pip3'
I've modified the .bash_profile file
echo 'export PATH="/Users/$USER/anaconda3/bin:$PATH"' >>.bash_profile
Both of these seem to work perfectly to modify their Terminal environments, when launched externally to VS Code. Neither seem to do anything to the environment launched from [cmd]+[`].
I've also tried conda activate base in the terminal, which seems to have no effect on a python --version or a which python
They can run things using python 3, but that means that they need to remember that they are different to the other 2/3 of the students. It's othering for them, and more work for me!
The students are doing fine, launching things from their external terminal, but it would streamline things greatly if the environments could be as consistent as possible across the OSs.
Whilst they are complete beginners, they can run a shell script. They currently have one that installs pip requirements and vs code extensions.
Is there a configuration that will keep the terminal in line with the debug env?
In my opinion the best practice is to create Python virtual environments (personally I love using conda environments, especially on Mac where you stuck with unremovable old Python version). Then VSCode will automatically (after installing very powerful Python extension) find all your virtual environments. This way you will teach your students a good practice of handling Python zoo a.k.a. package incompatibilities. Terminal environments settings will be consistent with VSCode, without being dependent on unneeded any more aliases. Obviously, virtual environments are OS independent, so you will be more consistent and remove unnecessary confusion between different students.
The additional bonus of the virtenvs is that you can create one exactly according to your requirements.txt and switch from one to another with a single click (in terminal it takes two commands: deactivate -> activate).
You can read more about how to handle Python virtual environments on VSCode site
Given the aliases are run just once and are not persistent in .bash_profile, python targets the default interpreter rather than the expected conda python3 interpreter.
Try to symlink conda's python3 executable to capture the python namespace
ln -sf /Users/$USER/anaconda3/bin/python3 /Users/$USER/anaconda3/bin/python
This will create or update the symlink. Use the same approach for pip and pip3.
Python in vscode let's you select which interpreter will be used to run the scripts.
It is in settings under "python.pythonPath", just set it to point to the interpreter of choice.
It can be set on a project basis as well (which is how you ensure that a project that has a virtual environment will execute using that interpreter and packages), you just select Workspace in the settings pane and add the desired python interpreter there.
Anaconda allows users to have different versions of Python and R installed at the same time. These versions are managed in environments, which can be activated and deactivated according to the user's preference.
I would like to specify which version of Python or R to use when I execute a script on the command line (regardless of which environment is active). This could look like
python -version 3.7 myPy3Script.py
python -version 2.7 myPy2Script.py
Here, the first command would execute my script in Python 3, whereas the second line would execute my second script in Python 2.
Can I actually do that in practice? If so, how?
Of course, I could just specify the path to the respective python executable. However, would the libraries be loaded correctly in this case? (See this issue). Also, would there be a way to avoid typing in lengthy paths?
Probably the easiest, and Anaconda's intended way, to specify which Python version to use is to activate your environment before each call. So something like:
conda activate <Python 3 env> && python myPy3Script.py
conda activate <Python 2 env> && python myPy2Script.py
Alternatively, if you are using Linux (or other Unix system), you can define a shebang at the beginning of your file to specify the program to execute the script with. So for instance, your myPy3Script.py might look like this:
#!/path/to/python3
<Code within your script>
...
I am trying to use Anaconda and conda environments to allow Python programs for data acquisition* etc. to run from the (Anaconda) command line on Windows. The set up will be that the Python programs are installed to a particular location (cloned from Github), within %PATH% or whichever environment variable is more appropriate.
From an Anaconda command prompt in another directory and a particular conda environment, I want (both myself and other users) to be able run either python test.py <args> or test.py <args> (either solution is acceptable) and have a system wide conda environment run its Python to execute the program. test.py can/will have an appropriate shebang set.
Right now the python test.py calls the correct Python within the active conda environment, but cannot find the test.py program as Python won't search the %PATH% or similar looking for the program. test.py does something (Windows does not complain that the executable can't be found, and I've been playing with the file associations to get this far), but doesn't appear to start Python - a simple print function or raise statement as the only entry in the file does nothing.
I've tried setting file associations in Windows, but this hasn't changed anything. I've copied the py.exe/pyw.exe across to the Anaconda environments, with no change.
Is this something that can be done within Anaconda, or am I going to have to fall back on installing base Python directly and trying to use the launcher mechanism there?
Note that I'm also intending to deploy these programs on Raspbian, so any solutions, including non-Anaconda ones, that will work cross platform there would be worth extra effort on my part.
*these programs have significant usage of library packages for accessing external USB/GPIB/serial/ethernet connected lab equipment and use matplotlib, scipy, etc., hence the desire for a cloneable conda environment as the base environment.
It turns out the correct answer to this is fairly simple, but is fairly hard to find explained well. This might be a little clearer than the other answers I found:
Install the standalone launcher from pylauncher and add #!/usr/bin/env python shebangs to your scripts.
This should register .py files to Python.File and will find your Anaconda Pythons in appropriate environments. If you don't have a non-Anaconda python, it will use the Anaconda base environment (these two facts were the key element I was missing from various other answers around this problem that I had looked at, including the documents on python.org).
If you have a Python from python.org installed, then a standalone command line shell will use that, defaulting to Python 2.x, then Python 3.x. With #!/usr/bin/env python shebang, then a regular command shell will try to use python.org pythons first, then the Anaconda base environment. An Anaconda prompt will use the active environment. #! /usr/bin/env python2 or python3 will try to use python.org pythons only and fail if they are not found.
Installing Python 2.7 from python.org installers (and letting the installer set the file associations) will break pylauncher, and reinstalling will not fix it. Instead, set Computer\HKEY_CLASSES_ROOT\Python.File\Shell\open\command default value to "C:\WINDOWS\py.exe" "%L" %* to revert back to the pylauncher set up (assuming you used the launchwin.* packages to install it).
this might be a very simple question but I need your help. I work in a network and I cannot install the programs I want. Anyway, I need to use another version of python, which is installed in the directory /new_version/.
Now, when I type "python" in a shell (I use bash) the command point to the version of python installed in the machine I'm working with. I'd love that when I type "python" this command point to the /new_version/ which I've installed. It would be also better if I can call this "new version" with another command, i.e. python2.
I tried changing the PYTHONPATH in the .bashrc but it didn't work.
alias newpython="/path/to/your/new_version/python"
Add this to your .bashrc, you can then start the new python with newpython and the standard one with python.
Add the line
export PATH=/new_version/:$PATH
to your ~/.bashrc (or ~/.bash_profile) file. Then, whenever you run python, it will find the new version first in your PATH. Note this is PATH, not PYTHONPATH. See the comment by #Aaron.
Edit: Only do it this way if you want python to point to the new version. Use an alias as #cularis suggested if you want to call it something different, or make a symlink with:
ln -s /new_version/python /path/to/a/dir/you/add/to/your/path/newpython
Install virtualenv. With this you can easily set up different Python versions like that:
virtualenv -p /new_version/bin/python
Also, virtualenv enables you to easily install other Python packages via pip install.
And finally, there's a package called tox which can automate testing with different Python versions...