3 ms·
The problem with out-of-band package systems is a lack of quality control, and accountability. Entire ecosystems emerged to handle Python Environment specific v
by Joel_Mckay 2y ago
The problem with out-of-band package systems is a lack of quality control, and accountability. Entire ecosystems emerged to handle Python Environment specific version issues, and often ignored a systemic underlying legacy library deprecation (same code may not work in 10 months).
Despite personal opinions on Rust use-cases/scope-creep (why not use a higher level llvm language if you want safer syntax.) Cargo like npm, php pear, and pip3 etc. traded convenience for long-term security rot, high maintenance cycles, and version instability within downstream source code.
i.e. the proponents will likely feel like they are in perpetual Beta, as dependent resources permute under conflicting use-cases.
People often confuse convenience with Workmanship Standards, and rotten code trees in any language have the same result. This is not a new phenomena ( https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect ) =3
- zelphirkalt 2y agoOnly recently had someone "update" a thing, and in the process throwing reproducibility and checksums all out of the window. Told that person, that they built a nice prototype, but that those things need to be reintroduced to the thingy. But that person doesn't see the need. I guess some people just build throwaways all day every day. When in 2 months someone else wants to build the thing, it might simply not build any longer, because that dude did not pay attention to reproducibility at all. This attitude seems to be wide-spread in Python land, unfortunately. Even prominent packages don't properly lock their versions and hashes. Many people deliver, I dare say, shoddy work.