On my Mac terminal i've installed python3 (3.7.6) using homebrew - e.g. if I issue command to upgrade via homebrew, it returns the up to date version:
$brew upgrade python3
Warning: python3 3.7.6_1 already installed
However when I ask for the version it tells me an older version (3.4.0) is installed:
$python3 --version
Python 3.4.0
So it's installed but not updated. I'd quite like 3.6 or later on my mac. I've tried uninstalling and reinstalling using homebrew, and had no luck. Wondering if anyone has any ideas?
//
Sidenote (1) - i'm relatively new to homebrew... $ brew doctor returns config scripts "outside your system or Homebrew directories" - not sure if this helps, and if this is the issue where to move them to.
/Library/Frameworks/Python.framework/Versions/3.4/bin/python3.4m-config
/Library/Frameworks/Python.framework/Versions/3.4/bin/python3-config
/Library/Frameworks/Python.framework/Versions/3.4/bin/python3.4-config
Sidenote (2) - 3.7.6 isn't the newest version out, but this is the latest version that homebrew will install. Is there any way to get an even newer version?
By chance i've come across the/a answer. I was editing .bash_profile and saw the very top says:
# Setting PATH for Python 3.4
# The orginal version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/3.4/bin:${PATH}"
export PATH
So I moved to this directory .../Versions/, found it had three subdirectories 3.3, 3.4, and 3.8, and updated to use:
PATH="/Library/Frameworks/Python.framework/Versions/3.8/bin:${PATH}"
And this seems to do the trick (to use the most recent). Although interestingly i've not came across 3.7.6... but is a bit redundant in my case since I can use the newer 3.8 version.
Quick fix:
You should be able to run the required version by running python3.7 instead of python3. You can set up an alias if you like with
"alias python=/usr/local/bin/python3.7"
where you put the desired binary on the RHS. This will create an alias for your current session. To always evoke this functionality, you can add this line to your bashrc file so this alias will work every time you log in to a new session
echo "alias python=/usr/local/bin/python3.7" >> ~/.bashrc
These commands were lifted from
https://opensource.com/article/19/5/python-3-default-mac
which explains some do and do-nots.
Alternative:
Also check out Python virtual environments, particularly virtualenv and virtualenvwrapper, which are great tools for separating out your Python working environments and allow you to set default Python version for each project separately, as well as managing any modules you pip install separately for each project. This is much cleaner in my opinion.
https://www.bogotobogo.com/python/python_virtualenv_virtualenvwrapper.php
Related
I have node v15.10.0 installed. I dont know how it was installed.
I found this article on how to update node. For mac it recommends using the official binary installer, which I did. It says the new version should overwrite the old version.
After installation, if I open a new terminal and do node --version, it stills says 15.10.0
The question is, how do I fully delete the old version, and install the new?
My path looks like this:
/Users/xx/.nvm/versions/node/v15.10.0/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/MacGPG2/bin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/opt/apache-maven/bin
I presume I could hack the path using a shell script, but is there a better way? Why did the installer not do this for me?
If we have to hack the path (for each user), which is the correct file? I see there is a .bashrc and a .zprofile in my home dir. They are not linked, but they have identical content, which is bazare, and they do not contain code to add /Users/xx/.nvm/versions/node/v15.10.0/bin to the path, so this must be set outside of either file?
I cant see 15 path in /etc/paths either.
I have no idea what shell you get in Mac now a days, but if I do ps -ef I see it mentions both bash and zsh.
Presumably I need to change the path on both ?
if you have nvm installed, the best way is :
nvm install 16
To switch between installed node version:
nvm use 16
To set default node version:
nvm alias default 16
Thanks to #AKX this was the solution:
nvm uninstall 15.10.0
Now I see v16.
I am using 18.04 Ubuntu with Anaconda.Recently i have trying to install OpenCV through conda-forge channel in the base environment. I did not install purposely any Python version and did not use any pip command either in base environment. Now, in the base environment, if execute just python, i get the same python version as system version and if execute python3 , i get the version installed by conda-forge. Please refer the screen shot. Python_on_Conda_base
I would like to know what is difference between python and python3 command?.What is should i keep in mind? basically i prefer the version 3.7.5 Python
.So, only the Python3 has uses different version. So, question what i should take note when i using python3 some_script.py? what is pros and cons of having this 2 version?
So far,i did not face any issues, but removed the conda-forge channel from Anaconda to avoid any conflicts. Any thoughts?
After posting this question, i have noticed python --version command gives Python 3.7.5 on Conda base environment and Ubuntu terminal (outside Conda)
You most likely have set an alias for python to point to the python3 binary.
Check this by typing type python, which will probably give you
python is aliased to ...
The crux here is that an alias will not be detected by which and as you revealed in the comments your which python returns the correct python version from your conda base environment, which makes an alias the most likely explanation, as PATH issues can be ruled out.
If above command does indeed reveal an alias, then check you .bashrc or similar file that you might have modified for a line alias python=.... Delete it, restart your terminal and everything should work normally
vincens#VMAC: python3
dyld: Library not
loaded:/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
Referenced from:
/Library/Frameworks/Python.framework/Versions/3.6/Resources/Python.app/Contents/MacOS/Python
Reason: image not found
[1] 25278 abort python3
python3 env is not used when I update my Mac to the latest version. How can I solve it?
This worked for me with the same issue.
Check if you have multiple Python3.x versions installed. In my case I had Python3.6 and Python3.9 installed. brew uninstall python3 did not remove Python3.6 completely.
I was able to call Python3.9 from Terminal by explicitly running python3.9 instead of python3, which led me to believe the issue was caused by ambiguity in which Python3.x resource was to be used.
Manually deleted /Library/Frameworks/Python.framework/Versions/3.6 resulted in Python3 running as expected.
hint:
It may be sufficient to remove /Library/Frameworks/Python.framework/Versions/3.6 from your PATH environment variable.
Check in the location:
/usr/bin/python3
If you can invoke python3 interpreter from this location without any issues, copy this to
/usr/local/bin/python3
I upgraded to macOS Big Sur and had faced the same issue. I was not able to open Python interpreter from terminal and the Python version inside Library/Frameworks/Python.framework/Versions/3.6 was also being pointed to Python2.7.
Later, I found python3 in location /usr/bin/python3 working fine for me. I also tried creating a symlink for python3 to the above path but didn't work.
That's becuase you have installed both python 3.6 from system library & python3.9 from other source like brew and there are something wrong with the python in lower version. Please manually delete the python within /Library/Frameworks. sudo rm -rf /Library/Frameworks/Python.framework/Versions/3.6 this command works for me.
I encountered this same problem on Step 1 of PyCharm's Create a Django project documentation.
I had previously set up Python on my Mac following these instructions. Can't promise this solution will work for everyone, but maybe if someone's Python was set up similar to mine the following solution that worked for me might help you...
Open Terminal
which python3
Copy the directory given to you... (For me it was /Users/foo/.pyenv/bar/python3)
When creating your new Django project in PyCharm (Professional Edition), set your base directory to the one received from which python3
Create your project
My case
Deleted Xcode (Maybe some folders are accidentally deleted like /Library/Frameworks/...
Also installed Python with anaconda.
My solution
Reinstall Xcode
Followed this to remove anaconda then everything works fine
I use Pycharm to create and manage my virtualenvs in my projects.
The problem is that after adding a library with pycharm, when I type the command (pip3 freeze --user), the library does not appear in the command result.
I have to manually type the pip install command each time so that the library is visible.
What manipulation should I do in PyCharm to solve this problem?
For what you are saying, the first thing that comes to mind is that you should use:
pip freeze
And not
pip3 freeze
Because the command mapped to the pip version when you have virtualenv activated is the first. Note that for installing you seem to use pip, and not pip3
Moreover, the --user option afaik is related to the packages installed in the user folder:
--user Install to the Python user install directory for your platform. Typically
~/.local/, or %APPDATA%\Python on
Windows. (See the Python documentation for site.USER_BASE for full details.)
If your packages are installed in the virtualenv folder, I would tell you to not use that option.
Also please make sure you have your virtualenv activated. In linux you can do so by source path/to/virtualenv/activate
Edit
I understand that the reason you are using pip3 is because you may have different versions of Python in your machine. Let me explain you a bit further how it works, because version management is usually a headache for many programmers and it is common to find problems when doing so.
If you install different versions of Python in your linux machine, and you do that as root, then the installation will proceed for the whole system. Usually Python2 installation folder for Linux machines is /usr/bin/python. However, I am uncertain of which directory is used for Python3 installations. You can check that easily by doing whereis python3. You can serach the path to binary of any command by doing whereis command. Note that this works also for whereis python as far as you don't have virtualenv activated.
Aditionally, the link to the binary of a command (or the set of instructions to be exectued, more broadly) is defined in certain folders in Linux, depending on whether you created the command as root or as a user, and possibly also on the distro. This works differently in Windows, that uses the Registry Edit utility to handle command mappings. When you enable your virtualenv, what you are doing is creating an environment that enables mapping system commands such as python to the Python installation in your virtualenv folder.
When you disable the virtualenv, the command points again to the default installation path. Same happens with pip, so incorrect usage of this tool may result in different packages being installed in different locations, and therefore not appearing available for the right Python version at any given circumstance.
In Linux, environment variables are shell dependent, though you can write them out with echo $variable and set them with variable=value (from bash). The search path is simply called PATH and you can get yours by typing echo $PATH.
Source: https://askubuntu.com/a/262073/426469
I encourage you to check other questions in SE network such as this: https://unix.stackexchange.com/a/42211/96121, to learn more about this.
Addendum
Quick tip: it is common to use the pip freeze command as follows:
pip freeze > requirements.txt
It is a standard that leads to understanding that modules in such file are required for the correct functioning of your application. That lets you easily exclude the virtualenv folder when you install the program in another computer, since you can readily know the requriments for a fresh installation. However, you can use the command as you want.
I am trying to install pysam.
After excecuting:
python path/to/pysam-master/setup.py build
This error is produced:
unable to execute 'x86_64-conda_cos6-linux-gnu-gcc': No such file or directory
error: command 'x86_64-conda_cos6-linux-gnu-gcc' failed with exit status 1
There are similar threads, but they all seem to address the problem assumig administriator rights, which I do not have. Is there a way around to install the needed files?
DISCLAIMER: This question derived from a previous post of mine.
manually installing pysam error: "ImportError: No module named version"
But since it might require a different approach, I made it a question of its own.
You can also receive the same error while installing some R packages if R was installed using conda (as I had).
Then just install the package by executing: conda install gxx_linux-64 to have that command available.
Source:
https://github.com/RcppCore/Rcpp/issues/770#issuecomment-346716808
It looks like Anaconda had a new release (4.3.27) that sets the C compiler path to a non-existing executable (quite an embarrassing bug; I'm sure they'll fix it soon). I had a similar issue with pip installing using the latest Miniconda, which I fixed by using the 4.3.21 version and ensuring I was not doing something like conda update conda.
See https://repo.continuum.io/miniconda/ which has release dates and versions.
It should now be safe to update conda. This is fixed in the following python packages for linux-64:
python-3.6.2-h0b30769_14.tar.bz2
python-2.7.14-h931c8b0_15.tar.bz2
python-2.7.13-hac47a24_15.tar.bz2
python-3.5.4-hc053d89_14.tar.bz2
The issue was as Jon Riehl described - we (Anaconda, formerly Continuum) build all of our packages with a new GCC package that we created using crosstool-ng. This package does not have gcc, it has a prefixed gcc - the missing command you're seeing, x86_64-conda_cos6-linux-gnu-gcc. This gets baked into python, and any extension built with that python goes looking for that compiler. We have fixed the issue using the _PYTHON_SYSCONFIGDATA_NAME variable that was added to python 3.6. We have backported that to python 2.7 and 3.5. You'll now only ever see python using default compilers (gcc), and you must set the _PYTHON_SYSCONFIGDATA_NAME to the appropriate filename to have the new compilers used. Setting this variable is something that we'll put into the activate scripts for the compiler package, so you'll never need to worry about it. It may take us a day or two to get new compiler packages out, though, so post issues on the conda-build issue tracker if you'd like to use the new compilers and need help getting started.
Relevant code changes are at:
py27: https://github.com/anacondarecipes/python-feedstock/tree/master-2.7.14
py35: https://github.com/anacondarecipes/python-feedstock/tree/master-3.5
py36: https://github.com/anacondarecipes/python-feedstock
The solution that worked for me was to use the conda to install the r packages:
conda install -c r r-tidyverse
or r-gggplot2, r-readr
Also ensure that the installation is not failing because of admin privileges.
It will save you a great deal of pain
After upgrading Golang to 1.19.1, I started to get:
# runtime/cgo
cgo: C compiler "x86_64-conda-linux-gnu-cc" not found: exec: "x86_64-conda-linux-gnu-cc": executable file not found in $PATH
Installing gcc_linux-64 from the same channel, has resolved it:
conda install -c anaconda gcc_linux-64
Somewhere in your $PATH (e.g., ~/bin), do
ln -sf $(which gcc) x86_64-conda_cos6-linux-gnu-gcc
Don't put this in a system directory or conda's bin directory, and remember to remove the link when the problem is resolved upstream. gcc --version should be version 6.
EDIT: I understand the sentiment in the comments against manipulating system paths, but maybe we can use a little critical thinking for the actual case in hand before reciting doctrine. What actually have we done with the command above? Nothing more than putting an executable (symlink) called x86_64-conda_cos6-linux-gnu-gcc in one's personal ~/bin directory.
If putting something in one's personal ~/bin directory broke future conda (after it fixes the C compiler path to point to gcc it embeds), then that would be a bug with conda. Would the existence of this verbosely named compiler mess with anything else? Unlikely either. Even if something did pick it up, it's just your system gcc after all...