I have nothing to do with this but still I am getting second hand embarrassment. Here is an example, is-arrayish package, 73.8 MILLION downloads per week. The code? 3 lines to check if an object can be used like an array.

I am sorry, but this is not due to not having a good standard library, this is just bad programming. Just pure laziness. At this point just blacklist every package starting with is-.

▲ zahlman 4 days ago | parent | next [-]

Meanwhile in Python: 134 million weekly downloads, seemingly slowly trending upward over time, for https://pypistats.org/packages/six which provides third-party compatibility for a version of Python that dropped support over five years ago.

▲

nromiun 4 days ago | parent | next [-]

The code is 813 lines [0]. Not saying everyone should use it but these two are not directly comparable.

[0] https://github.com/benjaminp/six/blob/main/six.py

	▲	zahlman 4 days ago \| parent [-]
		It is much more code, but it should be even more useless. (No slight intended to Benjamin Peterson.) The 2.7 window was already extended to give everyone a chance to migrate.

▲

rtpg 4 days ago | parent | prev | next [-]

Was a bit surprised at this, but looking into the packages in a work project that require six, a _huge_ chunk of them are packages that are still explicitly supporting Python 2.7 still (usually stuff related to operations).

I believe if you pay money to certain repo maintainers like red hat you can still have a supported version of Python 2.7.

▲

zahlman 3 days ago | parent [-]

> a _huge_ chunk of them are packages that are still explicitly supporting Python 2.7 still

Do you know if they also support 3.x?

Do you know if they're available on PyPI?

> (usually stuff related to operations).

What kind of "operations" do you mean?

	▲	rtpg 3 days ago \| parent [-]
		yes they also support python 3.x, are available on PyPI, and are related to operations in the sense of like... infrastructure management and the like. You have a huge pile of "sysop Python" out there interfacing with various infrastructure providers who are more interested in selling infra usage than getting off of Python 2. "In order to use our new storage service via our library you need to upgrade to Python 3 first" "ehhhhhhhh kinda annoying" That interaction has happened in the past. Time marches forward of course but.

▲

sega_sai 4 days ago | parent | prev [-]

Most of these downloads, I would bet, are from CI

	▲	zahlman 4 days ago \| parent [-]
		Oh, I don't doubt it at all. But that doesn't make it any less depressing to me. Nor does it matter to Fastly's bandwidth burden.

▲ junon 4 days ago | parent | prev | next [-]

I wrote it 10 years ago, I think before Node was v1, and forgot about it for a long time. This was back before we had spreads, classes, typescript, and had to use DOM arrays and other weird structures, and where `arguments` wasn't an array but an object.

    > (function() { return Array.isArray(arguments); })()
    false

▲

discomrobertul8 3 days ago | parent [-]

Do you think it might be time to deprecate and then retire this package, given that the ecosystem has evolved? Sure, it'll mean downstream packages will need to update their reliance on `is-arrayish` and use some other means suited to their task, but perhaps that's positive design pressure?

	▲	junon 3 days ago \| parent [-]
		Even if I sunset those packages, they'd still be downloaded and used in perpetuity, and certainly for many years afterward, even by popular packages, and even by such packages that have removed them in newer versions. Even if I had done this five years ago, I'd wager the scope of this attack would have been similar in size - maybe a billion less, but that's still a billion with a B, at which point I really wonder if it would have mattered as much. I agree that `is-arrayish` is silly, but that's not really the problem that needs fixing, in my opinion. There's a general, cross-language package management culture that has permeated over the last 10-15 years that is susceptible to this exact problem. It's TOTP today (in my case), something else tomorrow, and it can come to a Package Manager Near You at any time - npm is just a ripe target because of how much it's used, and how concentrated the download counts are for some of its larger packages, especially given how CI has started to operate (re-downloading everything etc). That's just my $0.02 on it though.

▲ quotemstr 4 days ago | parent | prev | next [-]

And at the other extreme, it takes TC39 seven years to bikeshed half of a decent implementation of Python's context managers: https://github.com/tc39/proposal-explicit-resource-managemen...

On one extreme, we have standards committees that move glacially, and on the other, we have a chaotic package ecosystem moving faster than is prudent. The two are related.

▲ tkiolp4 4 days ago | parent | prev | next [-]

You don’t get it. People don’t add “is-arrayish” directly as a dependency. It goes like this:

1) N tiny dubious modules like that are created by maintainers (like Qix)

2) The maintainer then creates 1 super useful non-tiny module that imports those N dubious modules.

3) Normal devs add that super useful module as a dependency… and ofc, they end up with countless dubious transitive dependencies

Why maintainers do that? I don’t think it’s ignorance or laziness or lack of knowledge about good software engineering. It’s because either ego (“I’m the maintainer of N packages with millions of downloads” sounds better than “I’m the maintainer of 1 package “), or because they get more donations or because they are actually planning to drop malware some time soon.

	▲	paulddraper 3 days ago \| parent [-]
		I think the real answer is far less nefarious. They personally buy into modularization, do-one-thing-do-it-well. Also engineering is fun, and engineering more things is more fun.

▲ 4 days ago | parent | prev [-]

[deleted]