January 18th, 2017

404

Евгений Чижов - перевод с подстрочника

Перед самим обзором. Что значит "книга временно недоступна" в магазине электронных книг? Я честно пытался купить. Не получилось.

Очень художественная книга. Довольно выразительна и жива, затягивающая нарративом и настроением героев.

Если бы речь шла про "просто жизнь", то было бы тревожно и приятно.

Но она - про среднеазиатскую версию 1984. Там, где Орруэл описывает двоемыслие и падение героя в это двоемыслие, как смертельный финал, у Чижова подробнейше и детально описано как именно это двоемыслие создаётся и поддерживается. Не как внешняя враждебная невозможная конструкция, а как глубокое, внутренее. Как честно старается герой достичь его, и какие ему страдания доставляет трудность достижения этого двоемыслия. Какая хрупкая и уязвимая конструкция это, как сложно её поддерживать, холить и лелеять.

При всей приятности текста, отличном языке, после прочтения остаётся лёгкий синдром очевидца насилия. Когда вроде бы не жертва, вроде бы не агрессор, а некая психологическая травма продолжает ныть, и возврат воспоминаний о книге ощущается как некомфортный и небезопасный.

В чём-то он слегка близок к Пелевину - но у Пелевина много межкнижных повторов, заумной плосковатой мистики, грубости и постмодерниского невкусного издевательства над читателем, а тут никакого постмодерна, только душеные терзания героя, и ничего кроме.

Так что скажу, что среди не-НФ, я эту книгу назову лучшей за последние лет 10, если не более.
404

Философия

Философия - это хардкорная научная фантастика, из которой вытерли персонажей, экшен и фантастические допущения.

Зато всё остальное - на 100%. Люди берут проблему и пытаются понять что из этого вытекает, какие последствия и как с этим жить. Пытаются по максимуму, без "провисающих моментов" и "роялей в кустах".

Пример современной философии: http://www.scottaaronson.com/papers/philos.pdf (Why Philosophers Should Care About Computational Complexity) (я уже постил эту ссылку если что)

И оно офигенно для чтения. Потому что поднимаемые там вопросы близки к уровню лучшей части футуримзма из фантастики образца Райта, Бенкси и Винджа.
404

pip vs deb

Главные причины, почему накручиваются всякие сложности в форме CI->repo->apt-get install:
1. Устойчивость к девиациям в состоянии системы. Если мы хорошо запакетировали библиотеку в deb-пакет, то она не упадёт при установке из-за отсутствия Python.h (системные зависимости не контролируются pip'ом). deb даёт устойчивость в этом вопросе: тут нет "случайно проскочило, но не должно было", более того, есть некий уровень автоматики по притягиванию нужных зависимостей (если мы используем apt). Можно это реализовать самому в системе управления конфигурациями или deploy скрипте, но это либо очень жёстко, либо неустойчиво, потому что устойчиво и гибко - это трудно. И это называется "система управления зависимостями". Которую можно написать самому, а можно взять готовую.

2. Гибкость к исправлениям и улучшениям. Процесс установки pip-install не подразумевает возможность влиять на устанавливаемый код. Если пакет из pip хочет сделать глупость, то не существует стандартного механизма по изменению этого. В сравнении с этим для deb есть хорошо отработанный workflow по наложению патчей на этапе сборки. Сами патчи трекаются, версионированы и контролируемы, более того, если у приложения есть тесты, то есть возможность выполнить их после наложения патчей не засоряя систему посторонними зависимостями (всякие tox/dox/sphinx/etc).

3. Готовность к удаляющим обновлениям. Если у нас pip install одной версии ставил foobar.py, а новой не ставит, то (я не знаю, но предполагаю, что) foobar.py не будет удалён из системы.

4. Бережное отношение к конфигам - они не перезатираются апстримовыми.

Всё это можно пойти и написать самим. Разумеется, никто этого не делает в полном виде, в результате чего, не-apt (rpm) деплой очень часто начинает выделывать коленца вокруг отсутствующих ручек для подкрутки. Финальное in-house решение чаще всего оказывается в одной из двух экстремальных ситуаций: либо оно более-менее гибко, и тогда расхлябанно-недетерменированное (что-то на сервер ставится, что именно - каждый раз никто не знает, ибо новое), либо намертво прибитое гвоздями в системе управления версиями так, что нет ни малейшей возможности что-то пошевелить в середине цепочки не сломав что-то в неожиданном месте.

Отсутствие одновременной гибкости и устойчивости приводит к более главной проблеме: альтернативные деплои (без участия apt/rpm) работают только если являются HEAD проекта. Если же такой вариант деплоя предлагается для библиотеки третьего порядка (т.е. app -> lib1 -> lib2 ->lib3), через цепочку языков (python -> go -> c), то обслуживание такого проекта становится неподъёмной задачей (при которой приходится либо гоняться за депенденсами из-за расхлябанности, либо бороться с "прибито гвоздями" в случае чрезмерной плотности).
404

python:Depends

Заинтересовался вопросом о том, кто его заполняет при сборке пакета. Выяснилось: его заполняет dh_python, однако, он использует для этого requirements.txt. А в моём случае в пакете его нет, а зависимости указаны в setup.py в секции install_requires.

Я пытаюсь понять - мне руками теперь из прописывать, или есть метод выковыривать из setup.py?

Вижу, что он должен писаться на этапе генерации egg_info. Более того, я его вижу в процессе сборки. Почему его игнорируют?