I find python packages quite easy to work with :) plus they're similar to ruby gems.

You create a venv or bundle, list requirements in a text file, then ask it to install things for you.

And if you need custom stuff, you can just pip install a .whl file, too.

I have yet to encounter a case where it's not working as expected, so my answer would be that python isn't getting fixed because it's not broken.

wontfix, works for me

KronisLV

> You create a venv or bundle, list requirements in a text file, then ask it to install things for you.

Just last week I had problems with a project that I hadn't touched in a while.

After installing Python 3 on a new computer (and making sure that pip is installed) I found that my scripts broke because "pip install" was no longer a thing. I now needed to do something like "python -m pip install".

Not a big issue, just a reminder that things are still improving for the better.

That said, whenever there's native code involved, things can get tricky (especially in Alpine based containers with musl instead of glibc).

That does apply to pretty much everything, just yesterday I also discovered that Ruby was slowing down builds 2-3x because of sassc install being really slow after an update. Then again, the whole library it depends on is deprecated so there's additional migration pain to be had soon.

And don't even get me started on database drivers and their prerequisites in each environment!

That said, even if something like Maven seems (sometimes) better due to no native extensions, I'm still happy that Python/Ruby/Node package managers work as well as they do. Sure beats copying random code manually.

rcarmo

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.

KronisLV

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/

rcarmo

"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.

KronisLV

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.