Ben Lindsay#Python question: When installing python using the official downloader on python.org, it sets up a symlink from /usr/local/bin/python3 to /usr/local/bin/python3.11, but it doesn't add a symlink from /usr/local/bin/python to /usr/local/bin/python3. Does anyone know why not? I'm an experienced python user, but this kind of threw me for a loop, because after doing the official python installation, `which python` still shows /usr/bin/python
For people who use this method, (@brianokken I think I've heard you promote it?) do you add that python ->python3 symlink manually or just type python3 everywhere or something else? I feel like I shouldn't have to type python3, since that's the default assumption these days, but I'm not sure if adding a symlink in /usr/local/bin will have side effects with the python installer or #homebrew or something else
Ed 👾🎮💻@benlindsay I usually create an alias to solve this problem.
@ede That makes sense. The part that gets me though is that I keep hearing the recommendation to use the official installer as the thing to recommend to beginners to help them fall into the "pit of success". Needing to create an alias for "python" to work instead of "python3" doesn't seem to fit that story
@benlindsay I think the problem is Python versioning and what ships with operating systems by default.
Many older programs may assume /usr/bin/python to be version 2 whereas /usr/bin/python3 is typically where Python 3 is installed and how it’s referenced. This includes PIP as well.
Typically, specific Python 3 versions (ie. 3.11) will symlink from /usr/bin/python3.11 to /usr/bin/python3.
Many older programs may assume /usr/bin/python to be version 2 whereas /usr/bin/python3 is typically where Python 3 is installed and how it’s referenced. This includes PIP as well.
Typically, specific Python 3 versions (ie. 3.11) will symlink from /usr/bin/python3.11 to /usr/bin/python3.
@ede That makes sense. But I think it's fair to assume that people working with legacy python2 stuff are more likely to be experienced devs who can figure out all the symlinking and version management stuff themselves, while new users are likely working with newer code where python 3 should be the default. The installation wizard should make python point to python3 by default and allow users to opt out
@benlindsay I think there may be some dependencies that may break if that happens.
Python 3 is not backwards compatible with 2 or earlier, so if a dependency exists in the environment, it may cause unexpected failures.
For example, macOS ships with Python 2.x. Replacing the symlink may cause a break for any macOS dependencies on Python 2.x.
Python 3 is not backwards compatible with 2 or earlier, so if a dependency exists in the environment, it may cause unexpected failures.
For example, macOS ships with Python 2.x. Replacing the symlink may cause a break for any macOS dependencies on Python 2.x.
Brian Okken@ede @benlindsay yep. I’m pretty sure that’s the reason. Newer macs don’t have the problem, so maybe a request to Python is in order.
It “should” only be an issue when creating virtual environments. Once in an active venv, the python link exists.
I actually like the absence of a global symlink, because it acts as a warning that I’m not in a virtual environment.
And even for new users, we should be teaching virtual environments, IMHO
It “should” only be an issue when creating virtual environments. Once in an active venv, the python link exists.
I actually like the absence of a global symlink, because it acts as a warning that I’m not in a virtual environment.
And even for new users, we should be teaching virtual environments, IMHO
@ede @benlindsay However, @brettcannon or other core devs might have better insight into the missing python symlink on macs.
@brianokken @ede @brettcannon Agreed about the importance of using and teaching virtual environments. Not sure I agree that the missing symlink is a useful warning...without the symlink, "python -m pip install" will install to the system python, and I think that's maybe more important to provide warnings or protections to avoid
Exploratory Data Alex@benlindsay @brianokken @ede @brettcannon I guess I'm a contrarian on virtual envs, but I stopped using them a year ago and the sky hasn't fallen for me. And for beginners, I think they add more complexity to the experience than the problem they solve is worth. Meanwhile pip has also gotten a *lot* better over the last couple years.
@benlindsay @brianokken @ede @brettcannon But this thread does make me wonder how much of the motivation to use virtual envs is coming from Mac-specific issues.
Robert Ritz@alexkyllo I'm on Mac (Apple Silicon) after switching from Windows. I used conda on PC and have used conda on Mac.
What got me was when JupyterLab Desktop came out. Simplified my life massively.
If I need something that doesn't work on M1 I have Docker Desktop or Deepnote.
@robertr @alexkyllo I use containers as well. It simplifies my development workflow and fixes dependency issues.
@alexkyllo @robertr I treat containers as a development environment, and use Tilt.dev for real-time coding and testing.
It’s really nice because it only rebuilds specific portions of my container when needed instead of having to rebuild everything every time I make a small change.
It’s really nice because it only rebuilds specific portions of my container when needed instead of having to rebuild everything every time I make a small change.
@alexkyllo @robertr I was writing a detailed reply and ran out of characters.
The key highlights are:
- Clean dev environment
- Versioning
- Automation
- Testing
- Portability
- Transferability
The key highlights are:
- Clean dev environment
- Versioning
- Automation
- Testing
- Portability
- Transferability
@alexkyllo @robertr A little bit of everything. My biggest use case ATM is security automation, but I write and maintain a lot of various Python-based tools.