Questions similar to this have been asked before, but I only can find explanations of the problem, not solutions.
I am running OS X Mavericks, and learning python. I installed Python but little did I know it was built in.
I use sublime text as my IDE, and I tried to install a few libraries (scipy, numpy, matplotlib). In Sublime Text, when I import the libraries, they work. I can import scipy and print scipy.pi perfectly. However, when I ran it in the terminal, it said it couldn't find those libraries.
Others have explained that the terminal is running the operating system's python and couldn't find the library, but didn't explain where one should place the libraries for it to run properly in the terminal.
Any help is appreciated, thank you
The short answer to your question is that you need to modify your PYTHONPATH environment variable to point to the modules that you want. If you're using bash (which you most likely are), you can do that like this:
export PYTHONPATH=$PYTHONPATH:'/path/to/your/modules/'
However, rather than running the OS X version of python, I would recommend that you run the python version that you installed. If you installed using the .dmg from python.org, you can probably just type 'python2.7' or 'python3' (depending on which version you installed) in the terminal and everything will just work.
If you want to, you can set the command 'python' to run the version of python that you installed rather than the OS X default python by putting in an alias or modifying your PATH environment variable in your ~/.bash_profile file. The easier option is to use the "Update Shell Profile" script that lives in the python folder after the installation.
One more possibility for you to mull over -- consider setting up a virtual environment with virtualenv, and installing scipy, numpy, etc. in there. This option might be more trouble than it's worth when you're first starting out, but in the long run it's a good skill to have and will make your development cleaner and easier to maintain.
Finally, since it sounds like you might be doing scientific computing, you could take a look at EPD free, which comes with many scientific packages preinstalled, and as a bonus will setup the necessary shell variables for you automatically.
You need to find out exactly what you are calling from Sublime Text. This solution ONLY applies if what others are saying is true and Sublime Text is calling another python interpreter that is different from the one that you are calling from the shell.
Step 1
Quick and dirty way to find out what Sublime Text is calling:
Make Python your build system. Select on menu bar: Tools > Build System > Python
Create new file (cmd+n)
Build (cmd+b)
This should give you an error message like this:
/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python: can't find '__main__' module in ''
[Finished in 0.1s with exit code 1]
[shell_cmd: python -u ""]
[dir: /Users/someuser/Downloads]
[path: /usr/bin:/bin:/usr/sbin:/sbin]
The first line is giving you the path to python interpreter that Sublime Text is using.
Step 2
Next, you should find out what you are calling in the command line:
% which python
/usr/local/bin/python
Using the information above, you can locate where /usr/local/bin/python is by:
% ls -la /usr/local/bin/python
lrwxr-xr-x 1 someuser wheel 33 Jul 29 23:14 /usr/local/bin/python# -> ../Cellar/python/2.7.5/bin/python
If that the two paths are the same, then stop: my solution will not apply to your situation.
Step 3
If the two paths are different, then you will need to either specifically use the path to the python interpreter that sublime text is calling:
% echo 'print "hello"' | /usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
hello
Or, if you like to just use python to call in command line, then you can change the link that came up by "which python" (e.g., /usr/local/bin).
e.g. (DO NOT COPY AND PASTE THIS - please understand where the paths came from and why):
ln -s PATH_TO_YOUR_PYTHON /usr/local/bin/python
For better discussion about changing default python on OSX, see "How to change which Python version gets used in Snow Leopard?".
Another thing - if you want to run different python from Sublime Text, then take a look at this.
Related
I am using MSYS2 as my terminal in Visual Studio Code for GCC support and to use a few tools that are easier to build often in a Linux environment. However, I would like to install Python on Windows and use that instead of Python packaged with MSYS2. My current workaround is to define the following alias in my .bashrc:
alias python='$PYTHONPATH/../../python.exe'
alias pip='$PYTHONPATH/../../pip.exe'
I recently tried using venv and that is causing problems as when I type python from the MINGW terminal, it points to my Windows python instead of the venv python. This is not a bug obviously, but I need a way to use Windows python instead of MSYS2 python for packages like numpy, tox, matplotlib, etc. because the MSYS2 packages for those are a headache and currently, tox+pytest in MSYS2 does not work. At this time, my solution above works for everything I've thrown at it in Python.
So, my question is how do I use my Windows Python install instead of the POSIX/Windows MSYS2 Python without the above hack? Is there a way I can define the PATH to include my Windows Python as the first entries in MSYS2 PATH?
Here is what it looks like right now:
$echo $PATH
/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Users/Glen.Nicholls/AppData/Local/Programs/Python/Python37/Scripts:/c/Users/Glen.Nicholls/AppData/Local/Programs/Python/Python37
I would like to know how to make it the following instead, delete python from MSYS2, or find another way to accomplish this.
/c/Users/Glen.Nicholls/AppData/Local/Programs/Python/Python37/Scripts:/c/Users/Glen.Nicholls/AppData/Local/Programs/Python/Python37:/mingw64/bin:/usr/local/bin:/usr/bin:/bin:...
You have to put the path for /c/Users/Glen.Nicholls/AppData/Local/Programs/Python/Python37 and /c/Users/Glen.Nicholls/AppData/Local/Programs/Python/Python37/Scripts before those on the msys2, right? Then I wouldn't try to use the terminal as it's too tricky, so, I will use the control panel to do it more easily. Here are some screenshots how I will do that for you.
(Sorry that I couldn't put the pictures, but the links for them instead, I couldn't put any pictures as I am a new member. Also, sorry I made the instructions too detailed.)
First, open search box with Windows+S key.
Then, choose the environment variables options from the window.
Then, choose the PATH system variable at the bottom section, and choose edit (the upper is the user PATH, and the bottom is the system PATH)
This is how it looked before:--
Then, choose C:/Users/Glen.Nicholls/AppData/Local/Programs/Python/Python37 and click “Move Up” until done. Likewise, do it same with “C:/Users/Glen.Nicholls/AppData/Local/Programs/Python/Python37/Scripts” until it's on the top.
This is how it looks now:--
After you are done, restart your terminal and hopefully, it will work. :D
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 recently had a problem with importing a python and therefore posted this question: Cant seem to import specific module in Python
Based on input I got I did some digging and saw the following:
If I open cygwin and input python --version, I get this
Marc#Marc ~
$ python --version
Python 2.7.12 :: Anaconda 4.2.0 (64-bit)
And if I open python using myCharm and input this:
import sys
print('\n'.join(sys.path))
I get:
C:\Users\Marc\Anaconda3\python.exe C:/Users/Marc/PycharmProjects/clustering/testing.py
C:\Users\Marc\PycharmProjects\clustering
C:\Users\Marc\PycharmProjects\clustering
C:\Users\Marc\Anaconda3\python35.zip
C:\Users\Marc\Anaconda3\DLLs
C:\Users\Marc\Anaconda3\lib
C:\Users\Marc\Anaconda3
C:\Users\Marc\Anaconda3\lib\site-packages
C:\Users\Marc\Anaconda3\lib\site-packages\Sphinx-1.4.6-py3.5.egg
C:\Users\Marc\Anaconda3\lib\site-packages\win32
C:\Users\Marc\Anaconda3\lib\site-packages\win32\lib
C:\Users\Marc\Anaconda3\lib\site-packages\Pythonwin
C:\Users\Marc\Anaconda3\lib\site-packages\setuptools-27.2.0-py3.5.egg
So assume this highlights the problem. Could anybody tell me what is wise to do here? Change the path in my terminal of change the path in python
If you set an envirnment variable called PYTHONPATH to a colon-separated (Windows: semicolon-separated) list of directories, each of them will be added to the interpreter's sys.path. This is the recommended way of making modules available.
So for example, let's suppose you had added Python modules in the directory C:\Documents and Settings\frits\private. Before you run your Python program you would execute the command
SET PYTHONPATH=C:\Documents and Settings\frits\private
No semicolon is required in this case because there's only one directory.
The when you run Python you will find that your sys.path has another entry corresponding to the C:\Documents and Settings\frits\private directory.
In the longer term, to avoid conflicts between the requirements of different projects (e.g. you want to run two programs that require a different version of the same third-party module) you should investigate the use of virtual environments.
I want to install python using homebrew and I noticed there are 2 different formulas for it, one for python 2.x and another for 3.x. The first symlinks "python" and the other uses "python3". so I ran brew install python3.
I really only care about using python 3 so I would like the default command to be "python" instead of having to type "python3" every time. Is there a way to do this? I tried brew switch python 3.3 but I get a "python is not found in the Cellar" error.
You definitely do not want to do this! You may only care about Python 3, but many people write code that expects python to symlink to Python 2. Changing this can seriously mess your system up.
If you're doing this for personal use, don't change the symlink for python. Many of your system programs depend on python pointing to Python 2.6, and you'll break them if you change the symlink.
Instead, pick a shorter name like py and write an alias for it in ~/.bashrc, like alias py=python3.
For example, with testing:
$ echo "alias py=python3" >> ~/.bashrc
$ bash
$ py
>>> 3+3
6
This will give you the convenience without effecting the system or other users.
If you are absolutely sure that you will never want to install / use Python 2, I think you can just create additional symlinks in /usr/local/bin.
Check for everything that links to something in
../Cellar/python3/3.3.0/
and create a link without the 3 at the end, like
python -> ../Cellar/python3/3.3.0/bin/python3
Think twice though, why give up the advantages of having two Pythons side-by-side? Maybe just use the homebrew Python as intended, and create your Python 3 environments with virtualenv.
Yes, far better to use [virtual environments] (https://docs.python.org/3/library/venv.html) for python 3 than mess with the system default
pyvenv /path/to/new/virtual/environment
which will setup python 3 as the default python and also isolate pip installs to that environment which is what you want to do on any project.
As mentioned this is not the best idea. However, the simplest thing to do when necessary is run python3 in terminal. If you need to run something for python3 then run python3
I am using:
Windows XP
Python 2.6.2 (standard install from python.org)
git version 1.6.5.1-preview20091022 (installed from http://code.google.com/p/msysgit/)
I have an environment variable looking like an absolute path (/path/to/dir) but I'm using it to construct a git URL. At some point, it's getting translated to C:/Program Files/Git/path/to/dir. It seems like Python is at fault:
In a git bash shell:
$ export VAR=/path/to/dir
$ echo $VAR
/path/to/dir
$ python
>>> import os
>>> os.environ['VAR']
'C:/Program Files/Git/path/to/dir'
git bash is not translating the path, but Python is?
In a Windows Command Prompt, Python gets it right:
C:\>set VAR=/path/to/dir
C:\>echo %VAR%
/path/to/dir
C:\>python
>>> import os
>>> os.environ['VAR']
'/path/to/dir'
Can anyone explain what's going on here? And how can I prevent the translation in a bash shell?
EDIT: I should add that my python script runs on OS X and Windows, so if anyone does have a solution it would be good if worked on both platforms.
The problem definitely sounds like it's caused by MSYS. When an MSYS process execs a non-MSYS process (e.g. your msysgit bash shell calling native Windows Python), the arguments are checked for anything that looks like an absolute POSIX path (e.g. things that start with a single '/') and these are translated to the underlying 'real' Windows path so that the non-MSYS program can find them. It's likely that this same process happens to the contents of your environment variables too, for the same reason.
This would be why removing the leading '/' works (the value doesn't look like a POSIX path any more), why adding an extra one works (ditto), and why this works fine under Cygwin (it's not MSYS). I'm also guessing that you installed msysgit at 'C:\Program Files\Git', and that this is why MSYS thinks its 'fake' POSIX file hierarchy is rooted there and adds it to the front of '/path/to/dir' for you.
Unfortunately, if that is the explanation then there isn't a clear solution. I hit a similar issue trying to pass remote paths through ssh and haven't found any good ways round this myself, and according to the discussion at http://comments.gmane.org/gmane.comp.gnu.mingw.msys/4511 (from 2008) there simply isn't an obvious fix beyond the workarounds you've found so far. If this turns into a bigger problem for you, you might want to raise it on the MinGW-MSYS mailing lists or bug tracker. According to the Gmane discussion, it had never been reported formally despite being a known issue.
My guess would be that this is not python at fault, but the git bash shell.
Maybe the git bash shell is lying to you when you look at the variable.
Or, try to not put the first / and add it again later (if translation does not occurs).
If I try with cygwin, it works:
$ export test="/bin"
$ python
>>> import os
>>> os.environ["test"]
'/bin'
The console you get from msysgit is probably modified for git user's needs, from my POV, it is only useful for simple tasks and to access git command line not to develop and run python scripts (you are using a Python installation for Windows in a shell installed for a specific application, that doesn't sound good).
You should install Cygwin and his python package (and even git package if you want) to get a correct POSIX environment with binaries and libraries prepared for it.