Hacker News new | past | comments | ask | show | jobs | submit login

Your PATH is broken and you’re not finding the pip wrapper for your install. If you need to install Python manually, use pyenv, which actually makes sure pip gets into your PATH to avoid that kind of thing.



Then I guess it's broken by default, considering that it was a pretty fresh install following whatever was the first Google result.

Regardless, someone actually advised against using PATH for pip because of confusion when you have multiple Python versions installed, which seemed like a sensible argument: https://snarky.ca/why-you-should-use-python-m-pip/


"following whatever was the first Google result"

That's your problem right there. Blindly doing that without understanding the way things work is an anti-pattern.

My point was that many Python distributions (especially in OS packages) split things up. If you need a custom Python or a specific version, use pyenv, which sets things up the right way.


Edit: actually just checked what's wrong again.

When running with cmd, I get an error about Python 2 being used instead of Python3:

  C:\Users\USERNAME>pip --version
  Fatal error in launcher: Unable to create process using '"c:\python27\python.exe"  "C:\Python27\Scripts\pip.exe" '
  C:\Users\USERNAME>pip --version
When running with Git Bash, I don't get any output whatsoever:

  USER@MACHINE MINGW65 ~
  $ pip --version

  USER@MACHINE MINGW65 ~
As it turns out, PATH has both Python 3 and Python 2 in it. Why is there also Python 2 on the machine? A legacy project that needs testing whilst migrating it over? Helping someone with an older script? Who even knows at this point.

My takeaways:

  1. following the first Google result (python.org and the official installer) wasn't the problem here
  2. Python 2 and Python 3 don't play nicely together, at all, might need to remove the old one from PATH to avoid headaches
  3. Specifying the Python interpreter to use (my example above, or better yet explicit python3) solved the issue
  4. Certain shells are weird sometimes, go figure
  5. What you're saying about pyenv is probably a good idea
Or maybe even something like PyCharm which lets you specify the runtime per project (much like you could specify which JDK to use with IntelliJ for Java).

Hopefully by the time Python 4 comes out and breaks everything, we'll already have figured out use cases like this (just kidding, sort of).

Node feels much the same way, especially because it moves ahead a bit more quickly with its releases and has less backwards compatibility when compared to Python. Somehow projects like Node Version Manager (https://github.com/nvm-sh/nvm) didn't really seem to gain much traction.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: