Nixtoo

Ну это же совершенно несущественная ерунда. У нас есть два файла, один module.nix другой module.py, и тот и другой надо прочитать с диска и выполнить находящийся в файле код тем или иным интерпретатором. Будет там функция, которую надо вызвать с определенными параметрами или выражение, или класс, который надо инстанциировать - да какая к черту разница то?

Я про то, что два куска кода не эквивалентны. В питоне можно писать в функциональном стиле, но это боль и страдания ввиду отсутствия нормальных лямбд, иммутабельных типов данных и кучи выпускников вузов, которые суют свой стейтфул ооп код во что ни попадя без задней мысли. nix для таких вещей более чем оправдан. Он вообще очень удобный как темплейтер, мне часто приходится с jinja2 возиться и это просто небо и земля

Как перестать мучать portage и начать изучать ansible?

Ну и AWX (обратите внимание, что к нему нет билда, ясное дело потому что это web-приложение). Я уверен, что некоторые посоветуют NixOS, но нет, просто нет.

Конечно, могли бы быть общие части у portage и ansible:

1. администиррование web
2. баз данных
3. сервисов systemd
4. разных инстансов приложений одной версии
5. управление монтированием слоёв слоёных файловых систем (типа overlayfs, раз уж она в ядре)

Но просмотром зависимостей я таких общих частей не выявил:

Вот зависимости Ansible:

app-admin/ansible ->
	app-admin/ansible-core

app-admin/ansible-core -> 
	dev-python/paramiko
	dev-python/jinja
	dev-python/pyyaml
	dev-python/cryptography
	dev-python/httplib2
	dev-python/six
	dev-python/netaddr
	dev-python/pexpect
	dev-python/resolvelib
	net-misc/sshpass
	virtual/ssh

Вот зависимости portage:

sys-apps/portage ->
	dev-lang/python-exec
	sys-libs/libselinux
	app-arch/tar
	sys-devel/patch
	sys-apps/baselayout
	sys-apps/coreutils
	sys-apps/file
	sys-apps/findutils
	sys-apps/install-xattr
	sys-apps/sandbox
	sys-apps/sed
	sys-apps/util-linux
	app-misc/pax-utils
	app-arch/zstd
	app-admin/logrotate
	net-misc/rsync
	app-portage/gentoolkit
	app-portage/repoman

Кроме того, как-то могло бы быть централизовано управление правами. Там целая отдельная история (единый ввход, двухфакторные аутентификации, kerberos, protocol transition и т.п.), а специализированного конфигуратора нет (portage создаёт пользователей с помощию специальных пакетов)

Дальше мысль идёт следующим образом: надо написать ebuild с именем вроде configuration/database-instances и из него повызывать ansible, раз уж именно эта утилита избрана на роль управления локальными инстансами софта.

Плохо, что удлиняется кривая обучения за счёт необходимости изучать Ansible. Да и управлять локальными (а не удалёнными) инстансами - это не совсем задача Ansible.

Я уверен, что некоторые посоветуют NixOS

Крутой комментарий, все по делу. Рад, что ты знаешь правильный ответ.

но нет, просто нет.

Не, если тебе это любо, ты продолжай страхивать бульдога с носорогом, чтобы получить буханку, а из нее уже троллейбус. Как наиграешься — приходи.

Мне тоже этот фрагмент документации непонятен: «the kernel, applications, system packages, configuration files, and so on — is built by the Nix package manager from a description in a purely functional build language. The fact that it’s purely functional essentially means that building a new configuration cannot overwrite previous configurations.»

Я не понимаю, как из факта использования функционального языка вытекает факт того, что новая конфигурация не может перезаписать старую.

Воспроизводимость на уровне пакетного менеджера/ос - отдельная от языка задача и методы её достижения от него не зависят.

А в документации другое написано. Врут, сволочи?

Ну переделай, я разрешаю