4 ms·

"The adoption of 3rd party libraries like numpy, which are so critical to modern Python, also destroyed the community's "batteries included" philosophy." You a

"The adoption of 3rd party libraries like numpy, which are so critical to modern Python, also destroyed the community's "batteries included" philosophy." You are right and your FreeBSD vs Linux analogy really hits the target. Thanks to the advancement of hardare and the development of libraries like Numpy, Python has moved from it's scripting niche and became a global, general purpose language. Was that an error? If we look at the "batteries included" philosophy and the poor state of Python's package management after all these years...I'd say yes.

DemocracyFTW2 4y ago
When I whined about Python's import system in another comment I completely forgot to add some snark concerning the horrible, horrible state of everything to do with Python package management system. Here again, many failed efforts over the years (setuptools, pip, ...), a terrifyingly convoluted packaging system, and bad, highly complex plans (virtualenv) to heal problems that are self-inflicted
- jimmaswell 4y ago
  I seldom use Python anymore but the few times I've used pip it's been fine. What went wrong with pip?
  - squar1sm 4y ago
    Asking people to run `pip install` on anything but `poetry` is an anti-pattern to me. Ruby has had bundler for over a decade and this is the pattern that is working for them as well as npm/yarn. Npm comes with node, Cargo comes with Rust so the debate is somewhat reduced. Since quality of life tools and other soft things are hard to prove, I'll tell my anecdata story point. I sought out any package manager experience in python. I landed on Pipenv which uses pip. It failed to solve the tree. This led me to find poetry and the reason for existing which is exactly my experience. That was 2-3 years ago. https://github.com/python-poetry/poetry#why https://github.com/python-poetry/poetry#why Combine this with asdf and it aligns with most other languages. asdf + yarn/npm = javascript asdf + poetry = python asdf + bundler = ruby asdf + cargo = rust asdf + mix = elixir asdf + shards = crystal asdf + go.mod (others) = go asdf + composer = php In legacy (don't break anything) mode, there's still no reason to not switch. I export `requirements.txt` with poetry just for pip legacy reasons and it works great. If I just update some scripts, I could avoid it. It's running all the time in CI, it's exercised quite a bit. What's wrong with just using pip and requirements.txt? There's no dev section. In addition, bumping deps is not the same. I have a blog post explaining semver updates to a python dev: https://squarism.com/2021/09/10/sciencing-out-updates/ https://squarism.com/2021/09/10/sciencing-out-updates/ my strong assertion: Python and Go missed it from the start. That's why it is so confusing. There's no other choice in Rust but Cargo. Rust devs are never confused on how to add a package, semver it. The answer is always Cargo. It's in the tutorial. It's in the book. It's in the culture. I think I've heard that pip might support the pyproject spec, poetry already does. If you want scripts like npm, you can have that too with "taskipy". You don't have to.

DemocracyFTW2 4y ago

When I whined about Python's import system in another comment I completely forgot to add some snark concerning the horrible, horrible state of everything to do with Python package management system. Here again, many failed efforts over the years (setuptools, pip, ...), a terrifyingly convoluted packaging system, and bad, highly complex plans (virtualenv) to heal problems that are self-inflicted

jimmaswell 4y ago
I seldom use Python anymore but the few times I've used pip it's been fine. What went wrong with pip?
- squar1sm 4y ago
  Asking people to run `pip install` on anything but `poetry` is an anti-pattern to me. Ruby has had bundler for over a decade and this is the pattern that is working for them as well as npm/yarn. Npm comes with node, Cargo comes with Rust so the debate is somewhat reduced. Since quality of life tools and other soft things are hard to prove, I'll tell my anecdata story point. I sought out any package manager experience in python. I landed on Pipenv which uses pip. It failed to solve the tree. This led me to find poetry and the reason for existing which is exactly my experience. That was 2-3 years ago. https://github.com/python-poetry/poetry#why https://github.com/python-poetry/poetry#why Combine this with asdf and it aligns with most other languages. asdf + yarn/npm = javascript asdf + poetry = python asdf + bundler = ruby asdf + cargo = rust asdf + mix = elixir asdf + shards = crystal asdf + go.mod (others) = go asdf + composer = php In legacy (don't break anything) mode, there's still no reason to not switch. I export `requirements.txt` with poetry just for pip legacy reasons and it works great. If I just update some scripts, I could avoid it. It's running all the time in CI, it's exercised quite a bit. What's wrong with just using pip and requirements.txt? There's no dev section. In addition, bumping deps is not the same. I have a blog post explaining semver updates to a python dev: https://squarism.com/2021/09/10/sciencing-out-updates/ https://squarism.com/2021/09/10/sciencing-out-updates/ my strong assertion: Python and Go missed it from the start. That's why it is so confusing. There's no other choice in Rust but Cargo. Rust devs are never confused on how to add a package, semver it. The answer is always Cargo. It's in the tutorial. It's in the book. It's in the culture. I think I've heard that pip might support the pyproject spec, poetry already does. If you want scripts like npm, you can have that too with "taskipy". You don't have to.