Vlákno názorů k článku
Python bojuje s fantómovými závislostmi
od RDa - Tak explicitni zavislosti by meli existovat jen pokud...
-
Tak explicitni zavislosti by meli existovat jen pokud je nutne vyzadovat konkretni verzi, anebo konkretni variantu nejake knihovny. Zbytek by se mel dat "vygrepovat" automaticky.
Ocekavat stav, ze kazdy tvurce bude upgradovat "minimal version" podle toho, zda je ona cizi knihovna zranitelna.. je celkem nahlavu. To jenom pridava zbytecny sum a praci.
-
Nad jaký průměr? Python je jazyk, který používají "skoro všichni" a těžko se tedy dá něco vynutit u většiny projektů. U JS není podle mě situace lepší, spíš naopak. A důvody jsou podobné.
U nás ve firmě si na tohle dáváme hodně bacha a zkoumáme před nasazením každou závislost, kterou přidáváme. A nepřeháníme to s nimi.
-
Ted jeste jak to tem vyvojarum-patlalum vysvetlit ze existuje i produkcni prostredi, dost odlisne od toho co ma on na stole.
Jako obcas narazim na takovy ustrel o jinde, ale jak je to v pythonu, tak to bejva skoro vzdycky jistota ze to bude v budoucnu problem.
Jazyk sam o sobe za to nemuze (doufam), to spis ta kultura, resp. jeji absence, co se okolo nej rozmohla.12. 8. 2025, 15:17 editováno autorem komentáře
-
Samozřejmě, protože se ten jazyk všude propaguje, jako že je to snadné a že to může dělat každý. Kód v něm vyrábí (dneska často pomocí AI) spousta neprogramátorů a se softwarovým inženýrstvím to nemá vůbec nic společného.
To není vyloženě špatně – pokud to těm lidem pomůže splnit úkol, třeba přeházet rychle data z jedné hromady na druhou a trochu je upravit nebo v nich něco najít, tak ať. Problém nastává ve chvíli, kdy se někdo pokusí ty ad-hoc skripty a prototypy použít v produkci a nechat je běžet bez dozoru na nedůvěryhodných datech zvenku. Nebo když čekáš, že ten skript bude fungovat nejen zítra, ale třeba i za rok (až se různé verze knihoven atd. změní).
-
Pavel TišnovskýZlatý podporovatelPyTorch má problém mj. i v tom, že na PyPi je jen plná GPU verze, takže se dotahuje i nějakých 6GB NVidia závislostí. A instalace z jejich "registry" https://download.pytorch.org/whl/cpu/torch_stable.html je dost nestandardní.
-
To ne, ten problém je v tom ekosystému mnohem hlubší, použil jsem torch jako příklad, kde je to jednak viditelné na hodně high profile oblasti, a jednak kde jde o spuštění dependency hellu mnohem hlouběji, který vede k nefunkčnosti. (on samotný. PyTorch je sám o sobě v pohodě, ale jsou na něm závislé další balíky, které mají vzájemné dependence typu xxx >2.56 < 3.0 přičemž pytorch 2.8 je podporovanej až z xxx 3.12), a dost často (jestli si dobře pamatuju, s rudým závojem a spoustou nadávek před očima se blbě pamatuje detaily) to skončí tím, že přes další 4 package musí být numpy > 3.xx a současně < 2.98 což pip vzdá.
K tomy tady je vyšší verze vynucená podporou HW (takže logická varianta zafixovat projekt na venvu s např. torch 2.0 nejde).
To jen pokud jde o samotnou funkčnost, pokud bychom se bavili o bezpečnosti, tak se obávám, že to peklo bude alespoň o 2 patra hlubší.
-
Zkusím to večer/zítra jak to vypadá aktuálně, ale třeba na tohle to narazilo (někdy v listopadu? jsem si s tim hrál naposled) v kombinaci A1111 při pokusu nainstalovat DreamBooth a ještě jeden plugin.
Ale jak říkám, torch jako takovej je v tom sám celkem nevinně, jen prostě spustí kaskádu někde mnohem dál.
-
Pavel TišnovskýZlatý podporovatel
no zpetna kompatibilita - mame projekt postaveny na balicku, ktery (zatim) celkem uspesne rozbiji kompatibilitu i pri zvyseni patch verze (coz ale souvisi s tim, ze to neni cislo zvysovany s kazdym patchem, ale tak jednou tydne). Mam na to soukrome (urcite zcela nepravdive) vysvetleni - praci SW engineeru tam delaji lidi z researche.
[Doplneni - Pythonni projekt]
12. 8. 2025, 19:27 editováno autorem komentáře
