61–70 of 79 posts
Earlier quoted context omitted.
> 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?
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
Earlier quoted context omitted.
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 clea…
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.
Earlier quoted context omitted.
Yes https://github.com/iree-org/iree-samples/blob/main/requireme... You can do even better using GitHub releases: the GET for a releases page with assets (ie use inspector) functions as an index url. So you can have a repo that publishes wheels to a release called eg `latest` that can function as the index for that package/wheel. You can even have multiple repos that publish to a single such wheel repo release repo (…
I don't know what "GitHub releases" are. And I don't want to know :) I prefer to use as few technologies as possible. And completely stay away from propriatary technologies.
This is the most boring and tedious archetype out there.
Earlier quoted context omitted.
> 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?
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
Earlier quoted context omitted.
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
It's not version 2 if it's an independent project.
Earlier quoted context omitted.
Packages are a language-level concept in Python. A package may be a collection of source files on the filesystem, it's still a package, except that doesn't lend itself well to distribution . Moreover, from the language standpoint, the usage of a package (like "import numpy") is the same on all architectures, but the files needed for distribution (native extension module binaries) may differ. Python is rife with Monty…
And here is the reasoning for naming it wheel: https://github.com/pypa/wheel/blob/3c7b6a0d13ee036ea8f6488ab... . Probably a reference to Monty Python as well ( https://en.wikipedia.org/wiki/Cheese_Shop_sketch )
https://tech.slashdot.org/story/05/08/01/0150222/pythons-che...
https://web.archive.org/web/20051027102030/http://cheeseshop...
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".
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…
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.)
Earlier quoted context omitted.
Yes, but if we just called them packages the headline would be "99% of top Python packages are now packages"
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.
Earlier quoted context omitted.
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.
That doesn’t make sense either because pure python packages exist and are actively less useful if distributed as wheels
It serves only as a further confusion. But yeah, Python is notorious for its numerous (and likely all sub-optimal) approaches to packaging.