...amíg a Python simán megy pip nélkül...
Ami semmit sem segít azon, ha a python szkriptnek bináris függősége van, és a megfelelő verzió nem érhető el a rendszerben.
...amivel menthetetlenül egybe lett gyógyítva...
Ott van pl az openssl-sys crate, ami a rendszerben lévő openssl shared library wrappere. Nem tölt le semmit, csak szól, ha a .so nem elérhető. Szóval koncepcionálisan a RUST együtt tud élni a rendszer csomagkezelőjével, ergo a Debian maintainer el tudná készíteni dpkg -ben a függőség fát, majd az upstream project függőség kezelését patch -ekkel tudná megfelelően módosítani. Innentől pont ugyan úgy kezelhető a függőség mintha C vagy C++ program lenne. Ha a python csomagokat újra tudják csomagolni akkor a cargo -val mi a gond?
De az a vita, hogy ki diktálja a függőségeket nem mai keletű. A disztrók saját csomagtárolói rendszerint lassabban frissülnek, cserébe stabilabb működést biztosítanak. A lassabb frissülés viszont biztonsági kockázatot jelent. Az upstream projektek szempontjából pedig szívás, hogy ahány disztró, annyi dudás próbálja diktálni milyen függőségek elérhetőek, és hol találhatóak. Az konzervatív megközelítés, hogy a disztró diktál, és az upstream lesz szíves alkalmazkodni, mert a rendszerbe nem telepíthet minden jöttment mindenféle dolgokat. Az új megközelítés, pedig, hogy az upstream lesz szíves hordozható csomag formátumban kiadni a termékét, ami downstream 1:1 -ben használható megfelelő izoláció mellett.
Esetünkben valószínűleg az a baj, hogy a Debian maintainer esetleg nem ért a RUST -hoz, illetve a wrapper csomag hierarchia elkészítése kezdetben sok meló. Az upstream peding nem elég rugalmasan áll a függőség kezeléshez (ott a cargo, majd én megmondom mi legyen). Erre teljesen jó megoldás hátralépni, hogy csinálja más, de nem tűnik úgy, hogy ez a RUST sara.