Recently, I've installed Anaconda3 in a MacOS laptop, but I need to set back the default python version to 2.7 because of some old codes involving the following syntax:
#! /usr/bin/env python
I read some comments and it seems like the easiest way to do it is by using an alias,
alias python="python2"
but even after setting this on my bash_profile, I'm still getting this:
$ which python
/anaconda3/bin/python
What am I doing wrong? Any suggestion is welcome. Thank you in advance!
IMO, you don't want to use an alias to do this. Rather, you want to manipulate your filesystem and/or PATH variable so that the first instance of a binary named 'python' found by the system on your PATH is the one you want to have running by default.
If it made sense to do so, and it was easy to do, an obvious fix would be to uninstall Anaconda. But I assume you still need it.
You could also dig into what the Mac might be doing in your case to manage multiple Python versions in some formal way. This might be the best solution, but I can't tell you how that works. You could Google for that information probably. If you want to take a more basic approach, read on.
What I'd suggest you do first is run the command ls -l `which python`. This will tell you which Python binary is currently the default one, and show you details about that binary. I'm guessing that that "binary" is actually a symbolic link, pointing to some other file. If so, you can just delete that link, or rename it to something else. The same thing will work if what you see is not a symbolic link, but rather a real executable, but it's a bigger deal to decide to delete or rename a real executable. If you just rename this file, you can obviously reverse what you've done any time you want.
Once you do this, do ls -l `which python` again. This should give you a new answer and be pointing at the original python installation. You can confirm which version of python is now the default by running python.
Related
I've got a script that requires python3.7 or above.
I've got multiple systems each with different python versions. all of them have either python3.7 or python3.8 but just "python3" can also be python3.6.
Is there a way to make a shebang line take either python3.7 or python3.8? and fail if none exist of course.
I tried a billion of options and nothing works. I was hoping for something like:
#!/usr/bin/python3.7 || /usr/bin/python3.8
or
#!/usr/bin/python3.7
#!/usr/bin/python3.8
but nada.. I also couldn't google it up which kinda makes me sad but who knows maybe the answer is there somewhere and I'm just using a bizarre jargon
these are not systems I can change defaults on and installing python3.7 on each such setup is sadly not an option (would make life awesome).
The shebang simply needs to point to an actual executable.
That executable can be one which finds a suitable version of the Python interpreter; see for example the py tool which was popular on Windows for a long time but which is now also being made available on real computers. other platforms.
Ultimately, something somewhere needs to be on the user's PATH, which obviously you will not always have control over. If you are targeting unsophisticated users, perhaps look into providing your code in a compiled executable, a prepackaged Docker image, or something vaguely like that.
We have a large number of scripts on an old CentOS system that begin with #!/usr/local/bin/python2.7. We are setting up a new host with RH EL7 and noticed that Python 2.7.5 is installed at /usr/bin/python2.7 instead of /user/local/bin/python2.7. This means that the old scripts won't be able to find python on the new RH system.
To avoid editing all the scripts, would simply adding at link at /usr/local/bin/python2.7 pointing to /usr/bin/python2.7 work? Is there a downfall to this approach?
Thank you!
On almost any modern distro, python points to python3 which in turn points to python3.7. So no, there's no down side to symlinking like this.
Just know what you're doing and why you're doing it.
Removed my comment and added it as an answer, since the question doesn't appear to be closing and others were posting information on the topic as answers.
Do it
"adding at link at /usr/local/bin/python2.7 pointing to /usr/bin/python2.7" is OK.
What is not ok is the other way round.
You put what you want in /usr/local/bin/, but avoid messing with /usr/bin/, which contains important stuff (but you don't do it so that's ok, just make sure you know what you're doing).
Xcode doesn't like symlinks, other than that, to my knowledge, there is no down side.
If you're on Mac (and use Xcode), you may want to read "Xcode, for whatever reason, will not let you use the symbolic link at /usr/local/bin/python" to fix that issue.
Edited to include a specific example
I am learning to use python and work in a windows 10 environment (although on 3 separate computers). I have gotten past the "add python to %PATH% issue" but continue to see odd outcomes when I call simple scripts from powershell compared to running them from the python terminal. For example, I often see that lines of code are duplicated, even simple print statements. A second repeating issue is that some (but not all) modules work fine in the python terminal but can't be found when running a script from powershell, despite using pip install within powershell to install it in the first place.
Rather then seeking help on a specific issue, I'm hoping for some guidance into how powershell and python interact that might help me understand or identify some commonalities in these issues I keep experiencing that are common from within powershell. If thats as simple as redirecting me towards another source even that'd be apprecaited. But my search results always turn up the common issue of powershell not knowing what python is, and needing to add python to the PATH. But as indicated, I have already gotten past this and can get %50 of my python to work from powershell. There must be something else perhaps obvious to others that I'm missing that can help me understand why some things aren't working while others are.
Thanks for taking the time to consider my problem and any advice is greatly apprecaited.
Here is an example from some code I am trying to get working, but in troubleshooting I have taken out a lot of code and am now only running what is shown that defines a dataframe and a print statement. Everything works line by line in python, but when I call the script from powershell, the print statement executes twice.
#!/usr/bin/python3
import pandas as pd
joedata = {'fpr': [0.2,0.4,0.8], 'tpr':[0.9,0.5,0.1]}
joeframe = pd.DataFrame(data=joedata)
print(joeframe)
Concerning modules, you probably have multiple versions of Python installed on your system. Calling pip in the Powershell doesn't mean that it will install for the Python installation which is called by default when you execute Python in the Powershell. So you should try to figure out on which version pip is installing packages and which version is actually used when executing a script.
EDIT: I tested the example that you gave in Powershell and I don't have the problem, it's working fine.
Moreover, for me, without doing any special configuration, in Powershell the commands pip and python refer to the same version of Python. If by default everything is ok, you should consider uninstalling Python and just running the installer again and let it manage the PATH, etc.
When I was loading certain modules [namely pygments.lexers Bash Lexer and pygments.formatters LatexFormatter] I was was getting an error that python couldn't find the modules. I then realised that this problem was being caused by my PYTHONPATH, which is set up for using paraview with python. It brings its own version of pygments, which doesn't work with nbconvert from the jupyter notebook for some reason [Note it is not totally disfunctional, as PythonLexer, and a few others were called without a problem, it was only the ones that I've mentioned above that couldn't be found].
I have a similar problem with mayavi, which wouldn't work with paraview's version of vtk.
Both of these problems can be resolved simply enough by commenting out the python path in the bashrc, but obviously then paraview won't work.
Is there any way to, for example, reduce the priority of the PYTHONPATH so that the system codes in /etc... are called preferentially, but paraview can still find the ones that it needs in the PYTHONPATH?
I am using python 2.76 on linux mint 17.3, paraview is version 4.4.0, installed from source code as per here
Ordering the entries in PYTHONPATH is partly right, but the system paths don't seem to get included until you run python, and then they get put at the end. So to put a system path in front, explicitly add it:
export PYTHONPATH="[path/to/system/files]:$PYTHONPATH"
It is kind of a hack, because the system path you add will be duplicated in sys.path. But it works.
Yes, you can import sys and manipulate sys.path as an ordinary list at runtime. You can rearrange what's there, or just insert at the beginning (sys.path.insert(0, 'path')). Do this before your import statement. If this will cause problems elsewhere, put it back after your import statement.
Note, this is fairly hacky. But it sounds like you might have a case for it, although I have not looked at these specific tools together.
Edit: this is more relevant if you want to control the python path at the level of individual imports within the course of one execution of python. If you want to control the path at the level of one full execution of Python, you can also set the python path on the command line for just that execution like this:
PYTHONPATH=/replacement/path/here python your_script.py
This is more verbose (unless you wrap it in a shell script or alias) than just calling python, but it lets you control the path one script at a time, wheres putting it into .bashrc/.bash_profile or similar changes it for your whole shell session.
export PYTHONPATH=$PYTHONPATH:<your_path> will give priority to system paths and only if something is not there will look on your path.
export PYTHONPATH=<your_path>:$PYTHONPATH will search <your_path> firstly and then $PYTHONPATH for what it does not find.
If something exists in both but you want to use one version of it for one program and the other for another then you might want to look on different bashrc profiles.
Anyone know this? I've never been able to find an answer.
If you're prone to installing python in various and interesting places on your PATH (as in $PATH in typical Unix shells, %PATH on typical Windows ones), using /usr/bin/env will accomodate your whim (well, in Unix-like environments at least) while going directly to /usr/bin/python won't. But losing control of what version of Python your scripts run under is no unalloyed bargain... if you look at my code you're more likely to see it start with, e.g., #!/usr/local/bin/python2.5 rather than with an open and accepting #!/usr/bin/env python -- assuming the script is important I like to ensure it's run with the specific version I have tested and developed it with, NOT a semi-random one;-).
From wikipedia
Shebangs specify absolute paths to system executables; this can cause
problems on systems which have non-standard file system layouts
Often, the program /usr/bin/env can be used to circumvent this
limitation
it finds the python executable in your environment and uses that. it's more portable because python may not always be in /usr/bin/python. env is always located in /usr/bin.
It finds 'python' also in /usr/local/bin, ~/bin, /opt/bin, ... or wherever it may hide.
You may find this post to be of interest:
http://mail.python.org/pipermail/python-list/2008-May/661514.html
This may be a better explanation:
http://mail.python.org/pipermail/tutor/2007-June/054816.html