[21:01:08] <nicksloan> Yeah. I know they aren't entirely to blame.
[21:01:52] <dstufft> nicksloan: heh yea, it's likely something similar could happen with PyPI, except we're too bogged down to answer support requests in a reasonable time frame (better UX through slacking?)
[21:07:05] <ngoldbaum> More detail: the "fs" package is a non-functional package. It simply logs the word "I am fs" and exits. There is no reason it should be included in any modules. However, something like 1000 packages *do* mistakenly depend on "fs", probably because they were trying to use a built-in node module called "fs".
[21:33:14] <nicksloan> Yeah. That's the amazing thing. Not too put too much on NPM's shoulders, but they certainly could have seen that trend and taken action to remedy the situation in advance.
[22:11:24] <nanonyme> Infinite deprecation policy is pretty dumb though
[22:11:37] <nanonyme> What's the point of deprecating something if you're not going to remove it?
[23:19:56] <[Tritium]> putting fs on npm is like putting os on pypi
[23:21:31] <[Tritium]> nanonyme: npm has the concept of flagging a package as deprecated - presumably to tell people to move to a different package. Just like doesnt generally remove releases, npm doesnt either (usually... the exceptions make tech news.)
[23:22:24] <tdsmith> i wonder if i can register that
[23:27:53] <[Tritium]> project for when I get home from work: go through and find all the standard library modules that that done exist on pypi... register them and create an sdist that intentionally fails with print("You dont need to pip install the standard library")
[23:28:44] <tdsmith> dstufft: do you have opinions wrt whether pypi should allow new registrations that conflict with stdlib modules :p
[23:29:47] <dstufft> Backports, also pulling something into the stdlib that was previously a third party thing, also new things being added to the stdlib that shadow stuff on PyPI
[23:29:55] <dstufft> not sure how If eel about it in general though