4 ms·

30 years later I still love programming but people given authority opting for cutesy names for critically important terms in the ecosystem should be severely li

30 years later I still love programming but people given authority opting for cutesy names for critically important terms in the ecosystem should be severely limited in their options. Flakes, pills, wheels, eggs... Come on, people. I am willing to bet good money that it won't hurt you physically if you just call them "packages".

boristhespider 3y ago
Yes, but if we just called them packages the headline would be "99% of top Python packages are now packages"
- pdimitar 3y ago
  Which would make the article completely redundant, and that works for me. :D But let's be serious, they could have just said "99% of the top Python packages upgraded to our new packaging system" which would be much more informative and interesting title and would make me read it in full, as opposed to now when I just facepalmed.
  - nickjj 3y ago
    > But let's be serious, they could have just said "99% of the top Python packages upgraded to our new packaging system" which would be much more informative and interesting title How about "99% of the top Python packages don't require being compiled to install them". That's one of the biggest wins of wheels. They have pre-compiled binaries for all supported platforms of that package. This typically applies to Python packages that have C dependencies.
    - pdimitar 3y ago
      And I would have never understood that from a cursory look at the article. Learned it just now from you.
      - adhesive_wombat 3y ago
        It's number 3 in "advantages of wheels", which is above the fold on my screen and exactly 50 words into the page, including titles.
        pdimitar 3y ago
        Fair enough, my point was that the terminology was a put-off. Reads like kids bragging about stuff and not as a technical article.
      - capableweb 3y ago
        So without understanding the reasoning why they are not simply called "python packages" but "wheels", so they have distinct meaning, you chose to go on a tirade about why they are not simply called "packages" instead? The confidence of some HN commentators never ceases to surprise me
        pdimitar 3y ago
        (EDIT: made myself sound less conflicting.) It's not such a stretch to want to understand things quicker as an outsider and be annoyed by a seeming gatekeeping via quirky witty terminology. Not sure why you used such a conflicting tone as an opposition of that -- I think, fairly reasonable -- stance.
  - gdprrrr 3y ago
    But the Python ecosystem reinvents package systems every few years, so that headline is also not very useful.
    - pdimitar 3y ago
      True, that's why I question the value of those articles in the first place.
  - Shawnj2 3y ago
    That doesn’t make sense either because pure python packages exist and are actively less useful if distributed as wheels
    - pdimitar 3y ago
      And I have no clue what you just said. :D It serves only as a further confusion. But yeah, Python is notorious for its numerous (and likely all sub-optimal) approaches to packaging.
      - Shawnj2 3y ago
        The benefit of wheels is that they’re platform specific so that you don’t need to have a lengthy and dependency ridden compile process, you just install the one that works on your OS and architecture and you’re good. Packages written entirely in Python don’t have this problem since the code is pretty much just copied into dist-packages
        pdimitar 3y ago
        I see, thank you, that's much better. I'd still try to shove the platform-specific stuff in a package manager and delegate that complexity to it.
        Shawnj2 3y ago
        For various reasons that’s often not an option
easywood 3y ago
You're completely right. The site doesn't even bother to explain what "eggs" are. And while it lists the benefits of wheels, there is no word about the apparent downsides of eggs, or maybe a little comparison table.
- frou_dh 3y ago
  The official documentation actually has a Glossary so they evidently do know that it's an issue. https://packaging.python.org/en/latest/glossary/ https://packaging.python.org/en/latest/glossary/
wiredfool 3y ago
Rpms, apks, debs, msi, exe, tarballs, zips, jars, wars...
- pdimitar 3y ago
  Well these are at least more or less known and widely used (though I agree if you never worked with Java that .JAR and .WAR will be confusing). But when a language ecosystem opts for cutesy niche names then they just end up confusing everybody, including some of their own users.
  - plq 3y ago
    I think JAR (Java Archive) and WAR (Web Archive) make sense. But wheel? It's a wheel of cheese, because pypi used to be called cheeseshop? I mean sure, but doesn't it feel a bit like that 20-year-old tatoo that you got during your teens that you got mixed feelings about today? My suggestion: Call them pypacks -- extension: .pyp
    - incrudible 3y ago
      JAR itself is a cutesy reference. You put your code in a jar, get it? WAR is perhaps not a cute reference, but it hints at what you'll be facing...
      - pdimitar 3y ago
        That's why I said jar/war are kind of the exception. They are still recognizable for many though, whereas Nix and Python's names are just WTF.
    - pdimitar 3y ago
      > I mean sure, but doesn't it feel a bit like that 20-year-old tatoo that you got during your teens that you got mixed feelings about today? That's exactly how I view all these "quirky" names btw.
    - firesteelrain 3y ago
misnome 3y ago
> I am willing to bet good money that it won't hurt you physically if you just call them "packages". So, "Packages are the new standard of distributing packages, and replace packages" is clearer to you?
- pdimitar 3y ago
  EDIT: Reduced my original comment to this: This only outlines that the article is very niche and not very interesting to be posted for non-Python audience. --- ORIGINAL COMMENT: Need I explain that if you arrive at such a title you would have to reevaluate if it's worth posting at all? Apparently I need to explain it. ;) This article is more or less pointless anyhow. Using better terminology would have made that clearer much earlier in the process IMO.
  - Balladeer 3y ago
    This "article" is a 10+ year-old website that's been tracking an ecosystem-wide migration from one style of preparing python code for distribution to another, more robust style of preparation.
    - pdimitar 3y ago
      This would have been an awesome introduction paragraph! Would immediately give context to bystanders like myself.
- jasonlotito 3y ago
  "99% of top Fooz packages are using new package system" vs "99% of top Fooz packages are lame"
- rvnx 3y ago
  You wouldn't have to say it even
- joe-user 3y ago
  To consider that the only option is rather reductionist. For example, simply add a version, and to use the original title instead of inventing one: > 99% of top Python packages are now on version 2
Demotooodo 3y ago
We are not even able to align all of this shit in one great platform. There is 0 reason why all of this is so unaligned. Alone how many people maintain packages for different Linux distirs etc. Maintain it once together and only promote it for your distri when you like it. Soooo much energy wasted
- Demotooodo 3y ago
  Imagine PackageHub: Allows for standard features like network of trust, signing, search, smart scanning, transformation into distri specific build flows from a meta format, statistics tracking, CDN, unified package API with dependency resolution and/or SDKs for this. It would also be much much easier to get sponsoring.
mschuster91 3y ago
This is, other than the fact it violates UNIX principles, my biggest issue with Homebrew.
- jen20 3y ago
  Which UNIX principles do you believe it violates?
  - mschuster91 3y ago
    Installing files in /usr/local/bin (a default path for all users) by an user that is not root. Absolute no-go.
    - jen20 3y ago
      It hasn’t done that in some time.
rkangel 3y ago
I get the issues, but using a fresh name that doesn't have pre-conceptions is often the better idea. If I call something a "package" people will have an immediate understanding of what "package" means, but it will be several slightly different understandings and that can cause quite subtle issues with learning and understanding. To talk about a different context the BEAM VM (Erlang/Elixir) has "processes". These aren't OS processes but pre-emptively scheduled threads of execution, scheduled by a userspace scheduler onto the available processor cores. They're similar to green threads or fibres in other contexts. They're called "processes" in Erlang because Erlang is old enough that the word process hadn't been implicitly co-opted to mean "OS Process", and it means that whenever I talk about Elixir scheduling I have to insert some version of the above explanation otherwise everyone gets the wrong idea. If they'd called them "florbs" instead, there would be no ambiguity. I still probably have to define the term, but I'm defining it against a universal blank canvas. Or to put it yet another way "All the good metaphors are already taken"
- pdimitar 3y ago
  As a guy who made a career out of Elixir (7 years now, though I have mixed and matched that with quite a bit of Rust and some Golang) I could not agree more on the confusing "process" moniker. My point was that calling packages "cheeses" and "wheels" was a conscious decision on the part of the Python community and apparently nobody stopped to think if it does not introduce friction or make them look unprofessional. As you pointed out, Erlang's "process" moniker came from a long long time ago and they have a good reason for it. Python though? 10 years ago many of these problems were well-understood already. Again, my argument is against cutesy quirky names. I get you that the generic "package" name carries some assumptions with it but IMO that's the more worthy battle to fight: to make sure everyone understands the same thing when "package" is mentioned. (EDIT: All that being said, Erlang could have indeed used a quirky name because what they have doesn't seem to have its own term yet. And it doesn't exist anywhere else I think.)
LoganDark 3y ago
They're not even packages. The package is the source code. A "Wheel" is a compiled distribution.

boristhespider 3y ago

Yes, but if we just called them packages the headline would be "99% of top Python packages are now packages"

pdimitar 3y ago
Which would make the article completely redundant, and that works for me. :D But let's be serious, they could have just said "99% of the top Python packages upgraded to our new packaging system" which would be much more informative and interesting title and would make me read it in full, as opposed to now when I just facepalmed.
- nickjj 3y ago
  > But let's be serious, they could have just said "99% of the top Python packages upgraded to our new packaging system" which would be much more informative and interesting title How about "99% of the top Python packages don't require being compiled to install them". That's one of the biggest wins of wheels. They have pre-compiled binaries for all supported platforms of that package. This typically applies to Python packages that have C dependencies.
  - pdimitar 3y ago
    And I would have never understood that from a cursory look at the article. Learned it just now from you.
    - adhesive_wombat 3y ago
      It's number 3 in "advantages of wheels", which is above the fold on my screen and exactly 50 words into the page, including titles.
      - pdimitar 3y ago
        Fair enough, my point was that the terminology was a put-off. Reads like kids bragging about stuff and not as a technical article.
    - capableweb 3y ago
      So without understanding the reasoning why they are not simply called "python packages" but "wheels", so they have distinct meaning, you chose to go on a tirade about why they are not simply called "packages" instead? The confidence of some HN commentators never ceases to surprise me
      - pdimitar 3y ago
        (EDIT: made myself sound less conflicting.) It's not such a stretch to want to understand things quicker as an outsider and be annoyed by a seeming gatekeeping via quirky witty terminology. Not sure why you used such a conflicting tone as an opposition of that -- I think, fairly reasonable -- stance.
- gdprrrr 3y ago
  But the Python ecosystem reinvents package systems every few years, so that headline is also not very useful.
  - pdimitar 3y ago
    True, that's why I question the value of those articles in the first place.
- Shawnj2 3y ago
  That doesn’t make sense either because pure python packages exist and are actively less useful if distributed as wheels
  - pdimitar 3y ago
    And I have no clue what you just said. :D It serves only as a further confusion. But yeah, Python is notorious for its numerous (and likely all sub-optimal) approaches to packaging.
    - Shawnj2 3y ago
      The benefit of wheels is that they’re platform specific so that you don’t need to have a lengthy and dependency ridden compile process, you just install the one that works on your OS and architecture and you’re good. Packages written entirely in Python don’t have this problem since the code is pretty much just copied into dist-packages
      - pdimitar 3y ago
        I see, thank you, that's much better. I'd still try to shove the platform-specific stuff in a package manager and delegate that complexity to it.
        Shawnj2 3y ago
        For various reasons that’s often not an option

easywood 3y ago

You're completely right. The site doesn't even bother to explain what "eggs" are. And while it lists the benefits of wheels, there is no word about the apparent downsides of eggs, or maybe a little comparison table.

frou_dh 3y ago
The official documentation actually has a Glossary so they evidently do know that it's an issue. https://packaging.python.org/en/latest/glossary/ https://packaging.python.org/en/latest/glossary/

wiredfool 3y ago

Rpms, apks, debs, msi, exe, tarballs, zips, jars, wars...

pdimitar 3y ago
Well these are at least more or less known and widely used (though I agree if you never worked with Java that .JAR and .WAR will be confusing). But when a language ecosystem opts for cutesy niche names then they just end up confusing everybody, including some of their own users.
- plq 3y ago
  I think JAR (Java Archive) and WAR (Web Archive) make sense. But wheel? It's a wheel of cheese, because pypi used to be called cheeseshop? I mean sure, but doesn't it feel a bit like that 20-year-old tatoo that you got during your teens that you got mixed feelings about today? My suggestion: Call them pypacks -- extension: .pyp
  - incrudible 3y ago
    JAR itself is a cutesy reference. You put your code in a jar, get it? WAR is perhaps not a cute reference, but it hints at what you'll be facing...
    - pdimitar 3y ago
      That's why I said jar/war are kind of the exception. They are still recognizable for many though, whereas Nix and Python's names are just WTF.
  - pdimitar 3y ago
    > I mean sure, but doesn't it feel a bit like that 20-year-old tatoo that you got during your teens that you got mixed feelings about today? That's exactly how I view all these "quirky" names btw.
  - firesteelrain 3y ago

misnome 3y ago

> I am willing to bet good money that it won't hurt you physically if you just call them "packages". So, "Packages are the new standard of distributing packages, and replace packages" is clearer to you?

pdimitar 3y ago
EDIT: Reduced my original comment to this: This only outlines that the article is very niche and not very interesting to be posted for non-Python audience. --- ORIGINAL COMMENT: Need I explain that if you arrive at such a title you would have to reevaluate if it's worth posting at all? Apparently I need to explain it. ;) This article is more or less pointless anyhow. Using better terminology would have made that clearer much earlier in the process IMO.
- Balladeer 3y ago
  This "article" is a 10+ year-old website that's been tracking an ecosystem-wide migration from one style of preparing python code for distribution to another, more robust style of preparation.
  - pdimitar 3y ago
    This would have been an awesome introduction paragraph! Would immediately give context to bystanders like myself.
jasonlotito 3y ago
"99% of top Fooz packages are using new package system" vs "99% of top Fooz packages are lame"
rvnx 3y ago
You wouldn't have to say it even
joe-user 3y ago
To consider that the only option is rather reductionist. For example, simply add a version, and to use the original title instead of inventing one: > 99% of top Python packages are now on version 2

Demotooodo 3y ago

We are not even able to align all of this shit in one great platform. There is 0 reason why all of this is so unaligned. Alone how many people maintain packages for different Linux distirs etc. Maintain it once together and only promote it for your distri when you like it. Soooo much energy wasted

Demotooodo 3y ago
Imagine PackageHub: Allows for standard features like network of trust, signing, search, smart scanning, transformation into distri specific build flows from a meta format, statistics tracking, CDN, unified package API with dependency resolution and/or SDKs for this. It would also be much much easier to get sponsoring.

mschuster91 3y ago

This is, other than the fact it violates UNIX principles, my biggest issue with Homebrew.

jen20 3y ago
Which UNIX principles do you believe it violates?
- mschuster91 3y ago
  Installing files in /usr/local/bin (a default path for all users) by an user that is not root. Absolute no-go.
  - jen20 3y ago
    It hasn’t done that in some time.

rkangel 3y ago

I get the issues, but using a fresh name that doesn't have pre-conceptions is often the better idea. If I call something a "package" people will have an immediate understanding of what "package" means, but it will be several slightly different understandings and that can cause quite subtle issues with learning and understanding. To talk about a different context the BEAM VM (Erlang/Elixir) has "processes". These aren't OS processes but pre-emptively scheduled threads of execution, scheduled by a userspace scheduler onto the available processor cores. They're similar to green threads or fibres in other contexts. They're called "processes" in Erlang because Erlang is old enough that the word process hadn't been implicitly co-opted to mean "OS Process", and it means that whenever I talk about Elixir scheduling I have to insert some version of the above explanation otherwise everyone gets the wrong idea. If they'd called them "florbs" instead, there would be no ambiguity. I still probably have to define the term, but I'm defining it against a universal blank canvas. Or to put it yet another way "All the good metaphors are already taken"

pdimitar 3y ago
As a guy who made a career out of Elixir (7 years now, though I have mixed and matched that with quite a bit of Rust and some Golang) I could not agree more on the confusing "process" moniker. My point was that calling packages "cheeses" and "wheels" was a conscious decision on the part of the Python community and apparently nobody stopped to think if it does not introduce friction or make them look unprofessional. As you pointed out, Erlang's "process" moniker came from a long long time ago and they have a good reason for it. Python though? 10 years ago many of these problems were well-understood already. Again, my argument is against cutesy quirky names. I get you that the generic "package" name carries some assumptions with it but IMO that's the more worthy battle to fight: to make sure everyone understands the same thing when "package" is mentioned. (EDIT: All that being said, Erlang could have indeed used a quirky name because what they have doesn't seem to have its own term yet. And it doesn't exist anywhere else I think.)

LoganDark 3y ago

They're not even packages. The package is the source code. A "Wheel" is a compiled distribution.