Ez történetileg kb. úgy szokott lenni, hogy a az összes sw (majdnem egy kernel nélküli disztrib, azaz egy együttműködő verzió konstelláció adott platformon, viszont akár adott gcc/libc/msvc/stb verzióval) egy adott könyvtárstruktúrában van, kb. ahogyan azt a MS Studio teszi. De nincsen debug és opt-ra korlátozva, és az összes (verzió) függőség implicit bele van drótozva. (az, hogy az AFS hogyan timeoutol egy dinamikus könyvtár távoli betöltésnél ekkora elosztott fájlrendszernél, az külön tészta).
Egy ilyen környezeteztet (legyen az dev sw.v1 és sw.v2-vel, dbg-al vagy production opt-al, vagy arm, x86, amd64 stb.) gyakran környezeti változóval állítanak a shell-ben. Amikor a shell korlátjai (pl. env var hossza betelik mondjuk egy pathnál) és a shell-függetlenség (bash, zsh, tcsh, cmd) már fenntarthatatlan, akkor a konfigurációkezelőt (gondolj pl scram, cmt és társaira mint cmake) lecserélik egy "teljes" nyelvre -- jellemzően python (kb. puppet) de lehetne ruby is (lásd chef).
Rengeteg proprietary konfiguráció-kezelő python script van ami adott verziószámot behelyettesít a path-ba, azt futtatási környezeti változóvá teszi, és ebben a világban él a build rendszer és fut annak terméke, maga a kívánt sw, "egy lépésre" innen a fakeroot-tól (OpenGenera és OpenVMS érdekesek ebből a szempontból). Gondolom az MS sem kivétel. A py-t lényegében egy perl/sh-nál fejlettebb ragasztónyelvként szokás használni ilyen kontextusban.