4 ms·

How does a language ecosystem that bakes "there should be one-- and preferably only one --obvious way to do it" into the interpreter* as a statement of values e

How does a language ecosystem that bakes "there should be one-- and preferably only one --obvious way to do it" into the interpreter* as a statement of values end up with such a convoluted packaging story? * Try running `python -c 'import this' | sed -n 15p`

stared 3y ago
Well, there are languages better at incorporating the Zen of Python than Python itself, vide (full disclosure: my blog post) https://p.migdal.pl/blog/2020/03/types-test-typescript/ https://p.migdal.pl/blog/2020/03/types-test-typescript/. When it comes to package managers, as you noted, the situation is even more ironic, as nicely depicted in https://xkcd.com/1987/ https://xkcd.com/1987/.
- surfingdino 3y ago
  What's your view on how Golang deals with this problem? Serious question.
  - zadokshi 3y ago
    Golang users don’t sit around arguing about package managers, nor do they have trouble with trying to make sure they have the right version of go installed. Early versions of go didn’t solve things well, but go has had this fixed for a long time now. Any arguments about packaging issues are likely related to older out of date problems people had. The only real problem people have these days is around private non open source packages. You can do it, but you need to learn how to set environment variables.
- mixmastamyk 3y ago
  One way to do things becomes impossible to after thirty years unless one wants to make large, breaking changes. After Python 3: >>> from __future__ import braces File "<stdin>", line 1 SyntaxError: not a chance
  - lijok 3y ago
    Haha, didn't know about this easter egg, amazing
  - endgame 3y ago
    That's been around since at least Python 2.6, and I think I remember seeing it before then: $ LC_ALL=C NIX_PATH=nixpkgs=https://github.com/NixOS/nixpkgs/archive/release-13.10.tar.gz nix-shell -p python26 --run 'python -c "from __future__ import braces"' File "<string>", line 1 SyntaxError: not a chance
    - mixmastamyk 3y ago
      “After Python 3” doesn’t mean it arrived then. It was supposed to be read, “after Python three … not a chance.”
yen223 3y ago
Because packaging is a very complex problem, and it's rare that any one packaging solution can get everything right in the first try. You will notice that every package management solution from all your favourite languages will have its own set of tradeoffs.
- lucideer 3y ago
  This is absolutely true, but I haven't seen any language ecosystems that have gotten things wrong as often as Python. And quite a few where the tradeoffs are minor enough to be well worth some sanity & consistency.
  - mixmastamyk 3y ago
    It's because no-one is in charge anymore, and Guido never cared about packaging anyway.
    - linsomniac 3y ago
      If you think Guido never cared about packaging, try calling it "The Cheese Shop" in distance of his hearing. :-)
      - mixmastamyk 3y ago
        Wasn’t any better back then. Not much of a cheese shop, is it?
  - rtpg 3y ago
    C++. I think Java is pretty close in nastiness but I haven't used it in a while.
    - lucideer 3y ago
      Java is Maven or Gradle mostly. Neither perfectly ideal but there's clear choices by subcommunitues (e.g. Android =>Gradle) & churn is low. Not at all an awful situation. C++ is mostly unmanaged in practice which is obviously bad (though Python is the only "modern" language where I regularly see published projects without so much as a requirements.txt so very comparable). However looking at the actual options for C++, Conan seems pretty clear cut & not awful in itself. So... not as bad as Python by any measure imo.
PurpleRamen 3y ago
Simple: Python is old. It predates most shiny languages by decades, and so does its packaging-trip. I mean, most modern packaging can shine today, because they could learn from the imperfections of their forerunners. Additionally, python has a very wide field to cover, far wider than most other languages, which makes things more complicate and thus people are more open for experiments, which leads to so many different solutions.
- lolinder 3y ago
  Python is old, but pip itself had its 1.0 release 8 months after Ruby's Bundler did and 6 years after Apache Maven, both of which are substantially better package managers than pip and both of which are also for 90s-era programming languages, not the new shiny ones. Age is part of the problem, but it's not the whole problem. Ruby manages to have a package manager that everyone loves, and Java has settled on a duopoly. Meanwhile Python has someone making a serious attempt at a new package manager every few years.
  - PurpleRamen 3y ago
    pip wasn't pythons first package-manager, and obviously wasn't it just created with version 1.0. There were already years of history at that point. But yes, Ruby has a better history with packaging, similar to Perl. Python was kinda always copying Perl and then Ruby in what they did, but still aiming to preserve their own identity and requirements. Which is also why nobody wanted to copy the cargo-cult-pain of the Java-Enterprise-World. > Meanwhile Python has someone making a serious attempt at a new package manager every few years. Many People have many attempts at many things in many communities. Doesn't mean they are important. Heck, vim and zsh have also dozens of different package-managers, and they have less use cases and problems to solve then python.
    - lucideer 3y ago
      > pip wasn't pythons first package-manager, and obviously wasn't it just created with version 1.0. There were already years of history at that point. All the more reason it should have been so much better if it has already had time to learn from & iterate on past efforts. Don't get my wrong, there's plenty of examples of projects ignoring well-known best practices (see the community backlash at Cargo's approach to name spacing or Homebrew loudly ignoring community feedback on FS permissions for 10+ years), but at this stage in 2024 you'd think we'd have gotten a little further than we have.

stared 3y ago

Well, there are languages better at incorporating the Zen of Python than Python itself, vide (full disclosure: my blog post) https://p.migdal.pl/blog/2020/03/types-test-typescript/ https://p.migdal.pl/blog/2020/03/types-test-typescript/. When it comes to package managers, as you noted, the situation is even more ironic, as nicely depicted in https://xkcd.com/1987/ https://xkcd.com/1987/.

surfingdino 3y ago
What's your view on how Golang deals with this problem? Serious question.
- zadokshi 3y ago
  Golang users don’t sit around arguing about package managers, nor do they have trouble with trying to make sure they have the right version of go installed. Early versions of go didn’t solve things well, but go has had this fixed for a long time now. Any arguments about packaging issues are likely related to older out of date problems people had. The only real problem people have these days is around private non open source packages. You can do it, but you need to learn how to set environment variables.
mixmastamyk 3y ago
One way to do things becomes impossible to after thirty years unless one wants to make large, breaking changes. After Python 3: >>> from __future__ import braces File "<stdin>", line 1 SyntaxError: not a chance
- lijok 3y ago
  Haha, didn't know about this easter egg, amazing
- endgame 3y ago
  That's been around since at least Python 2.6, and I think I remember seeing it before then: $ LC_ALL=C NIX_PATH=nixpkgs=https://github.com/NixOS/nixpkgs/archive/release-13.10.tar.gz nix-shell -p python26 --run 'python -c "from __future__ import braces"' File "<string>", line 1 SyntaxError: not a chance
  - mixmastamyk 3y ago
    “After Python 3” doesn’t mean it arrived then. It was supposed to be read, “after Python three … not a chance.”

yen223 3y ago

Because packaging is a very complex problem, and it's rare that any one packaging solution can get everything right in the first try. You will notice that every package management solution from all your favourite languages will have its own set of tradeoffs.

lucideer 3y ago
This is absolutely true, but I haven't seen any language ecosystems that have gotten things wrong as often as Python. And quite a few where the tradeoffs are minor enough to be well worth some sanity & consistency.
- mixmastamyk 3y ago
  It's because no-one is in charge anymore, and Guido never cared about packaging anyway.
  - linsomniac 3y ago
    If you think Guido never cared about packaging, try calling it "The Cheese Shop" in distance of his hearing. :-)
    - mixmastamyk 3y ago
      Wasn’t any better back then. Not much of a cheese shop, is it?
- rtpg 3y ago
  C++. I think Java is pretty close in nastiness but I haven't used it in a while.
  - lucideer 3y ago
    Java is Maven or Gradle mostly. Neither perfectly ideal but there's clear choices by subcommunitues (e.g. Android =>Gradle) & churn is low. Not at all an awful situation. C++ is mostly unmanaged in practice which is obviously bad (though Python is the only "modern" language where I regularly see published projects without so much as a requirements.txt so very comparable). However looking at the actual options for C++, Conan seems pretty clear cut & not awful in itself. So... not as bad as Python by any measure imo.

PurpleRamen 3y ago

Simple: Python is old. It predates most shiny languages by decades, and so does its packaging-trip. I mean, most modern packaging can shine today, because they could learn from the imperfections of their forerunners. Additionally, python has a very wide field to cover, far wider than most other languages, which makes things more complicate and thus people are more open for experiments, which leads to so many different solutions.

lolinder 3y ago
Python is old, but pip itself had its 1.0 release 8 months after Ruby's Bundler did and 6 years after Apache Maven, both of which are substantially better package managers than pip and both of which are also for 90s-era programming languages, not the new shiny ones. Age is part of the problem, but it's not the whole problem. Ruby manages to have a package manager that everyone loves, and Java has settled on a duopoly. Meanwhile Python has someone making a serious attempt at a new package manager every few years.
- PurpleRamen 3y ago
  pip wasn't pythons first package-manager, and obviously wasn't it just created with version 1.0. There were already years of history at that point. But yes, Ruby has a better history with packaging, similar to Perl. Python was kinda always copying Perl and then Ruby in what they did, but still aiming to preserve their own identity and requirements. Which is also why nobody wanted to copy the cargo-cult-pain of the Java-Enterprise-World. > Meanwhile Python has someone making a serious attempt at a new package manager every few years. Many People have many attempts at many things in many communities. Doesn't mean they are important. Heck, vim and zsh have also dozens of different package-managers, and they have less use cases and problems to solve then python.
  - lucideer 3y ago
    > pip wasn't pythons first package-manager, and obviously wasn't it just created with version 1.0. There were already years of history at that point. All the more reason it should have been so much better if it has already had time to learn from & iterate on past efforts. Don't get my wrong, there's plenty of examples of projects ignoring well-known best practices (see the community backlash at Cargo's approach to name spacing or Homebrew loudly ignoring community feedback on FS permissions for 10+ years), but at this stage in 2024 you'd think we'd have gotten a little further than we have.