Just reformatted my Mac to Yosemite and installed Python 2 & 3 using Homebrew. I've also setup some aliases in my bash_profile file which allows me to activate which version of Python I want to use. So if I type p3, it'll launch the python3 shell.
I'm wondering if it's possible to activate a specific version of Python without it starting the Python shell? So if I bring any files into the Terminal for instance, it'll use the version which I've activated?
Cheers!
Apologies if this has been answered elsewhere, I had a good search but I couldn't find anything.
Rather than writing your own scripts to manage different Python versions, I would suggest using a highly-used manager that has been tested in and out by the community: pyenv. With pyenv you can:
Easily install several different Python versions from the command line with no issues of them fighting (pyenv install 3.4.2)
Create virtual environments from any one of those versions if you want to compartmentalize the packages that are available (pyenv virtualenv 3.4.2 mypy3projectvenv), and
Set specific environments or versions to be active either
globally (pyenv global [version-or-venv]),
locally in and below folders you configure (pyenv local [ver-or-venv]), usually useful for projects that you have at a specific version/virtualenv, and
local to the shell until closed (pyenv shell [ver-or-venv]) (this is perhaps most-similar to your putative p3 command.
After setting the Python you want to use, all Python-related calls are redirected to their appropriate target (e.g. python, pip, easy_install, ipython*, django-admin*). Don't execute the Python scripts with any special command, just call them normally (or prefix a standard #!/usr/bin/env python shebang)
*If installed in that version/virtualenv
If you use the pyenv-installer script:
curl -L https://raw.githubusercontent.com/yyuu/pyenv-installer/master/bin/pyenv-installer | bash
Then add the couple lines it tells you to your ~/.bash_profile script (and either source it or restart bash)...you'll be up and running in seconds. The trick is usually installing all the Python build dependencies with brew (sqlite, OpenSSH, zlib...), but after that then you're golden.
Related
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.
This question already has answers here:
How to recreate a virtual env in python
(2 answers)
Closed 3 years ago.
I have two computers (running Ubuntu) that have access to one server. The shared home directory of the two computers is on the server.
On computer (A) python 3.5 is installed, on computer (B) python 3.7 is installed. I created a virtualenv from computer (B) on the shared home directory (using python 3.7).
Now although it is possible to activate that virtualenv from computer (A) it does not use the "virtualenv-python 3.7" but the system's python 3.5. So technically the virtualenv is activated but effectively it is not.
Note that the VIRTUAL_ENV path is set correctly.
I thought that virtualenv-folder is a fully enclosed environment, not even needing any python installed on the system. So why is it not working?
A virtualenv doesn't have a full Python installation. Instead, it links to an installation present on the system (FYI that link is in <env>/lib/orig-prefix.txt). The env's directory tree has some stubs and special logic but it uses the bulk from that installation.
So if you run activate on a system that doesn't have the same Python at the same path as the one virtualenv was created for, that script won't work correctly. It might happen to hook to something else present at the same path but this is not a supported scenario so all bets are off.
If you need a "fully enclosed environment", you may want to take a look at pyenv which does exactly that -- installs a full Python under your home dir. (Or you can just install Python from source to somewhere under your home dir -- but pyenv makes it easy to switch to that installation and back.)
The short answer is because on both computers A and B, the path to your python is likely just an alias. You can verify this by following the path on computer B and using the OS's GUI you can see it is a symlink to the actual python installation sitting somewhere else on your machine (probably usr/bin/). For example, on one machine where multiple installations of Python is found, I see that my virtual environment (.virtualenvs/revconnecion/include/python3.6) is an alias to the original /anaconda3/include/python3.6.
Solution:
You can create your virtual environment by specifying the python version itself when creating your environment:
python3.7 -m venv sharedvenv
or:
virtualenv -p python3.7
You can also manually change the symlinks / alias but the above method works better. Using the specific version of Python itself to create the virtual environment leaves no ambiguity and explicit is better than implicit.
Run which python on both Computer A and B to verify that it's pointing to the right version of Python.
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).
I have a full python installation with files in /usr/local/, but also have one that I compiled from source sitting in ~/python_dist. If I look at sys.path on each interpreter I see that they indeed import from different libraries.
Currently I can run $ PYTHONPATH=~/other_py_libs ~/python_dist/bin/python to invoke the custom interpreter with some other modules available in the path. However, I don't want permanently change the global PYTHONPATH variable.
How can I permanently change the python path for only one specific python install?
The easiest way to do this is to use a virtualenv (manage with virtualenvwrapper). With virtual environments you can set up different, isolated python environments (kind of like little python playgrounds). Switching between them (with the help of virtualenvwrapper) is as easy as typing workon envname. You don't have to worry about switching the PYTHONPATH around, and you can direct scripts to use a specific environment simply by running them with the python install in that environment, e.g. using #! /home/myname/.virtualenvs/envname/bin python.