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".
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"
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.)
So, "Packages are the new standard of distributing packages, and replace packages" is clearer to you?
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.
vs
"99% of top Fooz packages are lame"
> 99% of top Python packages are now on version 2
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.
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.
The confidence of some HN commentators never ceases to surprise me
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.
It serves only as a further confusion. But yeah, Python is notorious for its numerous (and likely all sub-optimal) approaches to packaging.
I'd still try to shove the platform-specific stuff in a package manager and delegate that complexity to it.
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
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.
But when a language ecosystem opts for cutesy niche names then they just end up confusing everybody, including some of their own users.
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
Though I suppose people already struggle to keep pip vs pip3 vs pip3.9 vs pip3.10 vs pip3.${n} vs pipx vs pipenv straight.
Jokes aside, I feel like the names on python are no more terrible than what Java does.
That's exactly how I view all these "quirky" names btw.