I recently installed epd python distribution in ubuntu. This got installed in the folder /home/jai/Downloads/epd_free-7.3-2-rh5-x86_64
Can you tell me how to make this python as my default python?
I get errors while running a test program (it seems my default python is different and it doesn't have numpy library, other libraries that come along epd python distribution.)
My test program is here: http://www.southampton.ac.uk/~fangohr/computing/download/python/tests/testall.py
The "default" python depends on how you're invoking it.
On Ubuntu, python is normally installed as /usr/bin/python (not /bin/python) -- which may be a symbolic link.
If you invoke the python command, e.g.:
$ python myscript.py
it will use whichever python executable is in a directory that appears first in your $PATH. You can modify your $PATH, either for your current shell:
export PATH="/some/dir:$PATH"
or for all future shells by updating your $HOME/.bashrc, $HOME/.bash_profile, or whatever. /usr/local/bin is one common place to put system-specific executables, or $HOME/bin for user-specific executables.
If you want to execute the script itself, you'll need a shebang as the first line of the script:
$ head -1 myscript.py
#!/usr/bin/python
$ ./myscript.py
...
You can edit the shebang to refer to whatever Python executable you want to use.
You can replace /usr/bin/python with your preferred Python executable, but that might cause unwanted side effects; existing Python scripts that assume /usr/bin/python is the default might break.
Another option is to change the shebang to:
#!/usr/bin/env python
which lets you execute the script directly while still using whichever python is first in your $PATH. This may or may not be a good idea; see my answer to this question for further discussion.
Default python is the one found in /usr/bin directory with the name python. Making a symbolic link of :
ln -s /home/jai/Downloads/epd_free-7.3-2-rh5-x86_64 /usr/bin/python
Assuming that is the name of the python executable, not the installer. After you installed, use the path where you installed it. f.e /home/iai/myNewPythonInstallation
might do the trick.
Most likely default 2.7 python is occupying that name, so you need to remove that, or use another name like epdPython. Then running python scripts would happen with:
epdPython myscript.py
Related
I have installed Anaconda 2 & 3 in my system. Anaconda 2 contains python 2.7 & Anaconda 3 contains python 3.6.
I need to run my python code using command prompt & I need to use python 3.6
While I'm running python --version, I'm getting python 2.7.14. How do I change it to python 3.6?
As you can see, I have both Python2 and Python3 installed.
I hope you know that the path of the python executable has to be added to the PATH environment variable in Windows. As you can see, the path of Python2 is placed above the path of Python3 in my system.
How does the cmd run commands?
It searches for an executable with the same name in the directory the cmd has been opened in, then goes and searches for the command in the locations provided in the Windows PATH variable, from TOP to BOTTOM.
Which means, it gets the path to Python2 before it can get to the path of Python3. Therefore, every time you type python in your cmd, it runs Python2.
Both Python2 and Python3 executables have the same name in Windows so it never runs python3.
What seems like an obvious solution?
You might think, changing the name of python.exe to python3.exe for the Python3 executable will solve your problem. You are partially right, it will work. But you have to use python3 file.py or python3 --version, which I think, is understandable. But, pip will no longer work if you change the name of the original python executable. You will no longer be able to install external packages and modules.
How can this problem be solved?
You can create an alias for the Python3 executable called python3.bat.
.exe and .bat files can be called from the cmd directly without using their extension. We always write python filename.py instead of python.exe filename.py although both are correct. The same can be done with .bat files.
Go back to the first image and notice the python3.bat file below python.exe. That is my way of calling python3 without renaming my original python executable.
python3.bat
Create a new file using notepad or something and paste this %~dp0python %*
I don't fully understand how this works except that dp0 basically runs python from inside the same directory and %* passes all the arguments to the python executable. Place this file inside your Python3 installation directory and your problem will hopefully be solved.
python3 basically runs your python3.bat file, which in turn runs the python.exe from its folder and passes the arguments to it.
I hope this solves your problem.
You should have python3 also in your path. You could use python3 to run your script:
python3 <your_script>
But to answer your question, you could use alias and update it as python.
$ python --version
Python 2.7.6
$ alias python=python3
$ python --version
Python 3.6.4
If you want to run Python 3.6, then execute python3.6.
Otherwise, check with which python where the symbolic link to the actual python executable is. On my system, it's
/usr/bin/python
and when I ls -la /usr/bin/python, it gives
lrwxrwxrwx 42 user user 42 Aug 24 03:45 /usr/bin/python -> python2.7
If you are really sure that you want to do it, you can now just move the old symlink somewhere:
sudo mv /usr/bin/python /usr/bin/old_python
and create a new symlink:
sudo ln -s /usr/bin/python3.6 /usr/bin/python
Now you should get something like:
$ python --version
Python 3.6.5
I don't guarantee that it doesn't break everything in the world, especially if you have some distro that has a package manager that relies on a specific python version under python.
This seemed to work nicely on Linux Mint 18.
I made a small trick to solve this problem. For me
C:\Python27
and
C:\Python27\Scripts
were at the top of the PATH Environment variable list. I simply selected them and clicked on Moved Down to shift them to the end of the list.
Just make sure that your path of Python3 and its Script folder is above Python2 path.
And it solved the problem for me. Hope it would help you too.
Reason :
How does the cmd run commands?
It searches for an executable with the same name in the directory the cmd has been opened in, then goes and searches for the command in the locations provided in the Windows PATH variable, from TOP to BOTTOM. Which means, it gets the path to Python2 before it can get to the path of Python3. Therefore, every time you type python in your cmd, it runs Python2.
Both Python2 and Python3 executables have the same name in Windows so it never runs python3.
reason is taken from the accepted answer to this question.
In order to run your script with python 3 you can use
python3 <path to file>
P.S.: this should be a comment, but I do not have the required reputation. :)
If Anaconda 3's is the only python3 interpreter in the system you can run python3 instead of python in your command line and it should work.
You can alter PATH parameter inverting the positions of both interpreters.
I have two versions of the python which the first path is python 2(I am still working with python 2), but there are some scripts which should use python 3. This is what I have done:
I have create a bat file.
ex:
open Notepad++ and write :
#echo off
set PYTHONPATH=
"%~dpn0.py" %*
save it as 'yourscriptname.cmd'.
before my script(which should use python3) I just run this file in command line and then run my script. it is working.
As a habit, I always specify a default interpreter at the top of a .bash/.py script. I just noticed that it causes me issues with virtualenv, because the interpreter directs to /usr/bin/python instead of the venv one. So I'm thinking, when and when not should one specify an interpreter this way?
If your script is made executable, your operating system will know which interpreter to use
Given a file named my_script that is executable and starts with
#!/bin/bash: your OS will us /bin/bash to interpret the script
#!/usr/bin/python: your OS will use /usr/bin/python to interpret the script
But one caveat is - as you noticed when using virtualenvs - that people do not necessarily have the same path for their interpreter.
A workaround and a good practise is to use the env utility to invoke a command.
#!/usr/bin/env python will use the first python found in your path, which in your case will be your virtualenv's python
I have a machine running OSX Yosemite (it has been through several versions of OSX, which may make a difference).
I noticed an anomily with whether python could import libraries depending on whether the script was run directly, i.e.
./Myscript.py
Or by expressly calling python
python Myscript.py
Now, if I type
$whereis python
/usr/bin/python
And my shebang line in the script is
#!/usr/bin/python
So I assumed that the same version of python was running in both cases.
But after investigating I find
$python --version
Python 2.7.6
$/usr/bin/python --version
Python 2.7.10
So it would seem that the python being executed is not the one I get when I do a whereis
Can anyone please shed some light on this, and also clarify how to fix it? I really want to be running 2.7.10 in both cases, since right now when I install libraries they go into 2.7.6, but when I run scripts, they run 2.7.10 and can't see the libraries.
Thanks
Jon
Don't use whereis, that command ignores your PATH environment variable. From the manpage:
The whereis utility checks the standard binary directories for the specified programs, printing out the paths of any it finds.
Emphasis mine.
You have a PATH environment variable that includes a 'nonstandard' binary directory. Use which to find where python comes from:
$ which python
which gives you the actual binary used for your current shell configuration:
The which utility takes a list of command names and searches the path for each executable file that would be run had these commands actually been invoked.
You could use which -a to find all possible completions for the command:
$ which -a python
Also see “whereis” and “which” return different paths in Mac OS X on Super User.
Demo:
$ PATH=/opt/homebrew/bin:$PATH whereis python
/usr/bin/python
$ PATH=/opt/homebrew/bin:$PATH which -a python
/opt/homebrew/bin/python
/usr/bin/python
So even with PATH explicitly pointing to my homebrew directory, whereis ignores it. which finds it and lists it first (the -a argument made it look for more options).
I have 2 versions of python installed on my server.
Python 2.6 in /usr/bin/python
Python 2.7.8 in /usr/src
Python 2.7.8 install guide
How do I make python scripts use 2.7.8? instead of 2.6?
how do I set up an alias?
Thanks
Write:
#!<path to your python interpreter>
as the first line of the script your run. Then just execute it.
Other option:
<path to your python interpreter> your_script.py
There are multiple ways of doing this. First, I would suggest you check your $PATH environment variable to see if it holds the path to both of your python versions. If it doesn't, you can either add the path or simply make a symlink to it from /usr/bin/ and call it python2.7, for example.
Then you can use #Pavel's suggestion of specifying the path to the interpreter in the shebang of the file.
If you followed my previous instructions, your shebang should look something similar to the following.
#!/usr/bin/env python2.7
You could also use the second way #Pavel showed you, by simply calling the interpreter first in the terminal and pointing it to the script.
/usr/bin/python2.7 my_script.py
The best option you have, which I recommend, is using virtualenv as suggested before, but only if you want it for specific scripts. If you want it globally, I would suggest you read further.
Finally, if you want all your scripts to run under python 2.7 then I suggest you remove python 2.6 and install the 2.7 version from the package manager, the right way, and save yourself a lot of hassle.
I used the installer from http://www.python.org/download. The install appeared successful, and it dropped the Python 3.3 folder in my Applications directory. I ran the "Update Shell Profile.command" script it contained, and it prepended /Library/Frameworks/Python.framework/Versions/3.3/ to my path. Yet the Python version in that directory appears to be 2.7.5.
/Library/Frameworks/Python.framework/Versions/3.3 ls
Headers Python Resources bin include lib share
/Library/Frameworks/Python.framework/Versions/3.3 Python --version
Python 2.7.5
Also, ls /usr/bin | grep python shows:
python
python-config
python2.5
python2.5-config
python2.6
python2.6-config
python2.7
python2.7-config
pythonw
pythonw2.5
pythonw2.6
pythonw2.7
What have I missed?
There are multiple problems here.
First, you should not be running Python, the framework's executable. Framework executables aren't meant to be run, and it's really only a coincidence that this one happens to work.
Frameworks with programs meant to be run put them in a bin directory somewhere—either outside the framework (like /usr/local/bin) or inside it (like /Library/Frameworks/Foo.framework/Versions/X.Y/bin). By default, Python 3.3 does the latter.
And the programs inside the bin directory are all lowercased, not capitalized, so there is no Python to run.
Next, on Mac, and on almost every other platform in the world besides Windows, the current working directory is not part of your PATH. So, when you type Python --version, that finds Python somewhere on the PATH. The fact that you happened to have an executable of that name in the current directory doesn't mean anything (except that it's confusing to you). If you really want to run that file (but again, you really don't), you have to write ./Python instead.
Also, there is really no good reason to cd into the framework directory in the first place. Sure, you could run the file you want, from there, with the appropriate relative pathname: bin/python3, for example, but you don't want to.
Next, likely you're using a shell you already had running before installing Python 3.3. The Update Shell Profile.command script can be used to add Python 3.3 to the PATH for all future shells, or to spawn a new shell with that PATH, but either way it will not affect any existing shells. To solve that, you just have to start a new shell.
Next:
ls /usr/bin | grep python shows:
The /usr/bin directory is only for programs that are part of the OS. Programs you install yourself go in /usr/local/bin, or somewhere else on your PATH, instead. The Python installer has an option (although it may be hidden, I can't remember…) to put launchers in /usr/local/bin. And it also has an option—which you selected—to put its framework bin directory onto your PATH. But either way, it's never going to put anything in /usr/bin.
And finally, even after installing Python 3.3, the default python will still be 2.7. python3 and python3.3 will be 3.3, but python and python2.7 will be 2.7. See PEP 394 — The "python" Command on Unix-Like Systems for the rationale. But the short version is, there's all kinds of code that depends on Python 2.7 and isn't compatible with 3.3 that may be installed on your system, and you don't want it all to stop working.
So, putting it all together:
Create a new tab or window in Terminal.app.
Type python3 --version.
You may want to consider using a virtualenv:
$ /Library/Frameworks/Python.framework/Versions/3.3/bin/python3 -m venv ~/myvenv
$ source ~/myvenv/bin/activate
(myvenv) $ curl https://bootstrap.pypa.io/get-pip.py | python
(myvenv) $ deactivate
$ source ~/myvenv/bin/activate
http://docs.python-guide.org/en/latest/dev/virtualenvs/