tgoop.com/itpgchannel/575
Last Update:
Я, на самом-то деле, с какой-то частью этой критики согласен.
1) Совершенно не понимаю похвальбу "функциональным пакетным менеджером". Функциональный язык без side effect для построения описания сборки пакета - это не достижение, а какой-то трешак, как по мне. Почему я должен учить еще 1 язык, который мне больше нигде не пригодится, и погружение shell в которого, кстати, сделано на троечку?
Я считаю, что построитель промежуточного представления(ну, считай, готового скрипта для сборки) имеет право сходить в сеть, и что-то там сделать.
Важно не это, важно то, чтобы отображение содержания готового сборочного скрипта на uid ноды было консистентным. Функциональность языка для описания сборочных скриптов тут, возможно, полезна, но совсем не обязательна.
2) Пути в Nix/Guix уж слишком длинные. Я сначала тоже начал с hex-encoded sha, но потом:
* Укоротил длину хеша, чтобы пути влезали на экран. Я не считаю, что мы тут боремся с malicious package maintainer, который будет как-то пытаться сделать так, чтобы подставить зловредный пакет вместо незловредного. Я считаю, что мы тут боремся с "днями рождения", и uid покороче вполне подходит.
* Потом я заменил hex encode на base64, понятно, почему он компактнее? https://github.com/pg83/mix/blob/d12a0becd86f11b9b45222f6bc29e86f46a66249/core/utils.py#L20 Вместо +/= я взял две совершенно случайных буквы, 'PG', чтобы в путях не было какой-то дичи.
* Но меня очень угнетал тот факт, что эти две буквы незаслуженно часто появляются в путях, и я запилил base62 - https://github.com/pg83/ix/blob/main/core/utils.py#L17, после чего все стало совсем хорошо. В python из коробки есть длинная арифметика, поэтому я не стал жестить с оптимизациями этого кода.
BY commit -m "better"
Share with your friend now:
tgoop.com/itpgchannel/575