Názory k článku
Python bojuje s fantómovými závislostmi
-
zásadní problém pythonu je v tom, že nemá jen python závislosti, ale často se buildí různé C/C++/Rust moduly a ty mají svůj balíčkovací systém. Udělat poté rebuild nějakého balíčky ze zpravidla u pythonu nemožné, musí se ručně probrat zdrojové repo, dokumentace a dopátrat se k tomu.
Tak třeba probíhá implementace v nixpkgs, který tady je zmíněný nebo třeba podobně to dělá i conda balíčkovací systém.
Python je v tomhle největší peklo, všichni stahují binární bloby, při stahování z pypi se neověřují ani checksumy, netušíš, co je obsahem a pokus o build z repa končí v nekonečném debugování.
-
Pavel TišnovskýZlatý podporovatelTy buildy jdou dělat i u balíčků s nativním kódem. Vyžaduje to mít nainstalovaný ekosystémy (třeba GCC, Clang, Rust), ale my třeba hermetic buildy děláme - trvá to, ale jde to.
checksumy u wheels se snad ověřují ne? Když byl problém se sítí, tak to běžně padalo u špatných hashů. V lockfilech to vypadá nějak takto:
wheels = [
{ url = "https://files.pythonhosted.org/packages/63/97/77cb2450d9b35f517d6cf506256bf4f5bda3f93a66b4ad64ba7fc917899c/aiohttp-3.12.15-cp312-cp312-macosx_10_13_universal2.whl", hash = "sha256:802d3868f5776e28f7bf69d349c26fc0efadb81676d0afa88ed00d98a26340b7", size = 702333, upload-time = "2025-07-29T05:50:46.507Z" },
{ url = "https://files.pythonhosted.org/packages/83/6d/0544e6b08b748682c30b9f65640d006e51f90763b41d7c546693bc22900d/aiohttp-3.12.15-cp312-cp312-macosx_10_13_x86_64.whl", hash = "sha256:f2800614cd560287be05e33a679638e586a2d7401f4ddf99e304d98878c29444", size = 476948, upload-time = "2025-07-29T05:50:48.067Z" },
{ url = "https://files.pythonhosted.org/packages/3a/1d/c8c40e611e5094330284b1aea8a4b02ca0858f8458614fa35754cab42b9c/aiohttp-3.12.15-cp312-cp312-macosx_11_0_arm64.whl", hash = "sha256:8466151554b593909d30a0a125d638b4e5f3836e5aecde85b66b80ded1cb5b0d", size = 469787, upload-time = "2025-07-29T05:50:49.669Z" },12. 8. 2025, 12:25 editováno autorem komentáře
-
my to také dělat musíme, ale je to dost práce s každým balíčkem a ještě se tam objevují regrese. Občas není jasné vůči čemu to je v pypi builděno nebo jde vidět, že sice v kódu buildí proti nové verzi, při buildu používají asi nějakou cache a mají tam starou.
Mno, https://pip.pypa.io/en/stable/topics/secure-installs/#secure-installs. Wheels není vše, co pip stahuje, že a ty hashe přichází stejným kanálem.
-
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ý podporovatel
PyTorch 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
-
Závislosti jsou obecně větším problémem než je na první pohled zřejmé a to nejen v pythonu.
Doporučuju kouknout na moc pěknou přednášku:
https://www.youtube.com/watch?v=6JGH2g1a3PM -
"To pak stěžuje práci softwaru pro kontrolu zranitelností a podobných."
https://prirucka.ujc.cas.cz/?slovo=ste%C5%BEovat
https://prirucka.ujc.cas.cz/?slovo=zte%C5%BEovatSorry jako...
-
Řešení závislostí bylo přidáno do golangu v roce 2018/19: https://go.dev/blog/using-go-modules
A i předtím existovaly 3rd party nástroje.
Zrovna tohle je věc, co se mi na golangu líbí - jeden oficiální built-in způsob řešení závislostí, je to nekomplikovaný, všechno je zapinovaný a checksumovaný a navíc ani nemusím nic explicitně instalovat, vytvářet virtuální environmenty apod., stačí "go build/run", víc neřeším.
-
Neni nad prispevatele, kteri videli Go z rychliku nebo naposledy pred par lety :-)
Instalace z tagu
v2.0.1:go get github.com/user/repo@v2.0.1
Instalace z adresare
v2:go get github.com/user/repo/v2
Go striktni verzovani nevynucuje. Projekt vetsinou zacina instalaci z nestabiliho masteru. Stabilni tagy zacne pouzivat pozdeji. A az prijde prvni breaking change, oddeli dosavadni vetev pro udrzeni kompatibility. Jo, vic moznosti dela ekosystem slozitejsi, ale kdyz se hned nechcete ucit vsechno, zacatek mate jednodussi. Pozdeji, kdyz chcete jistou verzi, musite se podivat na stranky projektu, co pisou o instalaci zavislosti.
Node.js a Python vedou vyvojare k verzovani od zacatku. Ve verzovani je vetsi rad.
Kdyz jsem zacal s Pythonem, myslel jsem, si ze semver v nem plati stejne jako v Node.js. Chyba lavky. Zatimco u Node.js baliku se pri upgradu, ktery nejde pres major verzi, muzete temer spolehnout, ze vysledek bude fungovat, v Pythonu je to obracene. Pripomnelo mi to Rust, kde semver snad ignorujou schvalne.
Moje zkusenosti s kvalitou semver verzovani OSS baliku: Node.js > Python > Rust. V Go je verzovani nepovinne, takze by ho umistil jeste pod Rust. Proste se musite prizpusobit tomu, jak ekosystem funguje.
18. 8. 2025, 12:34 editováno autorem komentáře
-
Nejde o žádný nestabilní master. Go bylo navrženo tak, že se jedná o malé, jednoúčelové a funkční knihovny, takže žádný nestabilní master neexistoval a fungovalo i bez verzování.
Bohužel, z mojí zkušenosti plyne, že každé další v.něco v tom udělá jen nepořádek.
Programuje se po malých, funkčních a otestovaných blocích kódu.
-
Google ho dělal pro sebe a zároveň ho uvolnil, netají se tím, že to je jazyk pro ně.
Go is a programming language designed by Google to help solve Google's problems, and Google has big problems.
pokud jde o ty závislosti, sami to popsali https://go.dev/talks/2012/splash.article#TOC_7, je to jejich rozhodnutí a tak to je. Udržovat celý strom různých verzí programů, řešit upgrady v definici závislostí, to je vše, co jim nevyhovovalo.
Celý paradigma go je o tom, že buildíš často a pořád.
