I realize that this is probably a simple question but, I'm 95% my path is screwed up. The result of opening a new terminal and typing [echo $PATH] is:
/Library/Frameworks/Python.framework/Versions/2.7/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Users/bmoog/.rvm/bin
Looking around it seems that it should be something more like:
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/git/bin:/usr/X11/bin
Any guesses as to why I am going into my Python.framework?
The Python installers from python.org, and from many other sources, do not install anything into /usr/local/bin or /usr/bin. Instead, they install everything into a bin directory within the framework, and then give you an option to add that bin directory to your path. (Generally, any script that get installed either with that Python, or with packages you later install into it, also end up in the framework's bin directory.)
So, at some point, you ran a third-party Python 2.7 installer, and checked the checkbox/manually ran the post-install script/etc. to do this.
All the option does is prepend the following 4 lines to your ~/.bash_profile:
# Setting PATH for Python 2.7
# The orginal version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/2.7/bin:${PATH}"
export PATH
(Possibly with the typo orginal for original fixed, depending on your version.)
So, you can revert by just cp ~/.bash_profile.pysave ~/.bash_profile if you're not afraid of losing any subsequent changes… or, more safely, just edit the file in your favorite text editor and remove those lines.
Of course if you do this, you will no longer be able to run that third-party Python, or its 2to3, or an ipython you installed for it, etc., without specifying a horrible absolute path…
Meanwhile, you probably didn't need a third-party Python 2.7 in the first place. Apple has been providing Python 2.7 for at least three major OS versions now (2.7.5 in Mavericks, 2.7.2 in Lion and Mountain Lion), as /usr/bin/python. If you don't want this 2.7 on your PATH, you probably don't want it at all, so I'd just uninstall it.
Check your ~/.bash_profile and then all the files it includes to see where the extra path is coming from. Somewhere there will be a line like:
export PATH=/Library/Frameworks/Python.framework/Versions/2.7/bin:${PATH}
But do you really care?
Related
I installed python using the command:
brew install python3
Now when I use 'which python', path is '/usr/bin/python' and when I use 'which python3' path is 'usr/local/bin/python3'
Shouldn't it fetch the same path ?
As python3, which is a version, still falls under python ?
I just am not clear as to why different paths are thrown. Please Explain!
Python is a program, that will take inputs, and interpret them. How will it interpret them ? Following a set of rules, written in a lot of files. Where are these files written ? Somewhere the program knows. And by default, the 2 paths you have are the paths it knows where to go.
Python2 and Python3 have different files, because even if they have the same base, they are not same and behave differently. Hence the 2 differents paths.
Though, through the years, people have come up with solution to avoid these "python version collisions" on computers : it is called a virtualenv.
Virtualenv is basically a script that will contain a whole new python (at the version you wish you install it), and, when you "activate" it, you will be able to use python, and have the version you wish to develop with. Doing this, everyone is able to only use python and still use different versions depending of the program you with to use.
Example : You have python on your system which writes Python 2.7.12 when you do python --version. If you instantiate your virtualenv (see the doc), and then use python --version again, you might see something else along the lines of Python 3.6.8. Your former computer, or other scripts, can still use the previous python version, and you new script can use the new one, without any conflicts.
I've been going with a basic Python3.4 install that I've been installing many modules into for over the past month but have reached a point where pip is coming up short and I'm going to just install the full Anaconda on my system to go deeper into bokeh-server stuff.
I get a popup during the Windows 64bit installer (Anaconda3-2.3.0-Windows-x86_64.exe) saying
A version of Python 3.4 (64-bit) is already at C:\Python34\ We
recommend that if you want Anaconda registered as your system Python,
you unregister this Python first. If you really know this is what you
want, click OK, otherwise click cancel to continue.
Didn't find much documentation on this subject, and I'm not really sure how to "unregister" that installation of Python apart from uninstalling it entirely from Windows which I imagine would accomplish such a thing. Is this basically telling me to check how my Python Launcher for Windows is setup after the Anaconda installation? I'm completely unfamiliar with this notion of python system registration? Is that just a round about warning about which python version takes precedence on the system path, or which installation holds the file associations?
The solution is simply to uninstall python (for example, run the original python installer and select the uninstall option). The python key in the windows registry will be removed (which is what unregister means in this context).
Here is a link to a script that will unregister a Python installation (if you haven't come across it already). I personally have not dealt with anything like this. It seems like it should work, but you may have to tinker around with some of the paths in the script to get things to work. The links in #nightuser 's post will also probably fix the issue.
Why not just remove your version of Python? You could do a pip freeze > requirements.txt with your current Python and add them to Anaconda, or create an environment with Anaconda using those packages. Anaconda has greatly decreased the amount of time I spend setting things up.
You are getting that prompt because you have another version already installed the safe way to do this is going to the directory of the existing version and running the uninstaller. Once the previous version is completely uninstalled. You can run the installation as normal it should works!
enter image description hereYou have already installed python in your environment, so your system can handle your python code. Anaconda can handle your python code as well. If you install Anaconda and expect use python provided by Anaconda, then your system will confuse about assigning the code job. To avoid this confusion, there is always a path to point out which python you want.
You can ask your OS to find specific python by changing your environment path in windows OS:
By deleting the python path your Python will be invisible. Changing path is more convenient compared with the uninstall.
If you got a python compiling software like Pycharm, things are different. Pycharm may have python3.6 while your system got python 3.5. You need to delete path in those software or uninstall python specified by those software.
Pycharm
Actually, instead of registering the Anaconda as the system python, you can install it first, then specify your Pycharm and system path to the Anaconda python path. Thus, your Pycharm will use python provided by Anaconda and package & virtual environment you need.
I edit this for lots of times because I got Great wall, so I can't close something pop up in my screen(cause it is Blank). And everything is missing if I refresh. This is annoying.
My system path Anaconda3's python36
Add path in Pycharm
Or you can't use these packages and Anacon's virtual Environment
As described in: http://bugs.python.org/issue22139, the python27.dll is installed in the windows systems (in my case C:\Windows\Systems32) folder.
But I would like to know why? Why is it not installed next to the python.exe, for example in C:\Python27\?
Reason I ask: I've made a mercurial hook in python that our developers need to use to check if the commit message is valid. It checks a.o. for a valid JIRA issue number. To prevent all our developers to install python themselves and install the required modules manually (a lot of work and errorprone), I zipped the python installation and asked the developers to unzip it locally. But they can't run it, because the python27.dll is missing, or worse, they already have another minor version of python installed, and the hook will fail due to the wrong python27.dll used. Confusing.
If I just add the python27.dll (the correct version) to the zip file, it all seems to work great. So, why is it not installed in that location in the first place? What is the advantage of installing it in C:\Windows\System32?
Hope someone can explain this to me!
Thanks in advance,
Tallandtree.
I use the Anaconda Python distribution from http://continuum.io. They put python27.dll into c:\anaconda right next to its python.exe. This distribution is also superior in that you can have multiple python environments with precisely the packages you need and switch between them easily (http://conda.pydata.org/docs/using/envs.html). You can also get the package list of one of your environments and distribute it to others.
I recommend this Python distribution over the one from python.org and Enthought, because of this issue.
.dlls are quite windows-specific files. I imagine you will have shared object (.so) files for LINUX/UNIX-specific Python stuff? You said your developer's couldn't run it, because they didn't have the correct DLL (i.e. the one relevant to their Python installation).
Also, the advantage of installing it to System32 is that it's in the default PATH. Additionally, if any other application is internally using Python and require access to the .dll file, and also NOT reference your Python directory, they will probably be looking for a location that "Actually" exists (I wanted to say guaranteed to exist, but......never mind). That location would be `C:/windows/Systems32'.
I found it to work just fine to put python27.dll in the Python directory (c:\Python27 or wherever). As long as it's in the PATH, it seems to work. I did this for a "relocatable" installation of Python. I can copy the installation directory to a Windows machine that has no Python installed, set the PATH to include that directory, and run Python, including all the libraries I had installed with pip install on the original machine.
The Yosemite (OS X 10.10) upgrade includes Python 2.7.6, and the process, as usual with Apple system updates, seems to completely replace the system packages directory, in
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python
This time, the process appears to have entirely omitted site.py. My understanding was that this file was essential to the functioning of Python, in particular, the proper construction of package search paths; but my Python (which uses nothing more than the Apple system Python and additional packages in site-packages) works fine, and my paths remain as they were before the upgrade.
Is site.py no longer needed for proper functioning of Python? Has it been moved to another location?
site.py is still used. You are just not looking in the right location:
>>> import site
>>> print site.__file__
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.pyc
The /Extras structure appears to consist entirely of non-standard-library packages, e.g. packages that Apple installs for their own uses that are not included with standard Python.
If there was a site.py file there in previous OS X versions it was in all likelihood one installed by setuptools; with 10.10 comes setuptools 1.1.6, which has long since got rid of the hack embodied in that file.
If the behaviour of python hasn't changed and sys.path contains the path to your site-packages folder, you should be fine. If you use the interpreters -S option, the path to the site-packages folder won't show up in sys.path, so you can test it. I would recommend searching for the file on your system. If it doesn't show up, make sure you can see hidden files in case it's hidden for some reason.
site.py docs
edit: Resolved in comments, but wanted to provide an official answer.
How would I do this? The reason being I wanted to try some pygame out, but I have python 3 installed currently and have been learning with that. I'm also interested in trying out wxpython or something like that, but I haven't looked at their compatibilities yet.
EDIT:: im on a windows vista 64-bit
If you are on Windows, then just install another version of Python using the installer. It would be installed into another directory.
Then if you install other packages using the installer, it would ask you for which python installation to apply. If you use installation from source or easy_install, then just make sure that when you install, you are using the one of the proper version.
If you have many packages installed in your current python-3, then just make a zip backup of your current installation just in case.
Erm... yes. I just installed Python 3.0 on this computer to test it. You haven't specified your operating system, but I'm running Ubuntu 9.04 and I can explicitly specify the version of Python I want to run by typing python2.5 myscript.py or python3.0 myscript.py, depending on my needs.
Typically python is installed with a name like python2.6, so you can have more than one. There may be a symlink from python to one of the numbered files. Quite workable.
Yes, it is possible.
I maintain 3 python installations (2.5, 2.6, 3.0). The only issue that could be confusing is figuring out which Python version takes precedence in PATH variable (if any) . To execute a script for a specific version, you would go into the python directory for that version
C:\Python25\ , C:\Python26\, C:\Python30\, etc.
Drop the file in there, and run "python.exe file.py" from command-line.
You could even rename each python.exe to python25.exe python26.exe python30.exe and have each directory in PATH so it would be easy to execute any script on any version.
I would assume it'd be the same as running two versions of 2.x; as long as they're each in their own directory you should be OK.
You certainly can. On Mac Ports, there's a tool called python_select that lets you switch among python versions; if nothing like it exists on Windows (momentary googling didn't reveal one), it could certainly be written.
You can set up virtual python environments using virtualenv.