Но пока нет уверенности, что переход был бы оправдан.
Одна моя знакомая девушка говорила мне: "Пока сам не попробуешь, не узнаешь". Она, правда, имела ввиду совсем другое, но к Nix этот принцип тоже применим.
Как правило, у таких языков есть и свой пакетный менеджер, у которого lock-файл для воспроизводимости и автоматическая сборка пакетов, а нативные зависимости мы уже зафиксировали с дистрибутивом и его репозитарием.
Ага. Но если, например, проект на двух языках сразу, пакетных менеджеров становится уже два. Я не говорю, что надо всегда использовать Nix. Но в некоторых случаях его использование сильно упрощает жизнь.
Писать сборку чужих зависимостей на nix не очень круто, потому что окружение nix ни на что не похоже: во-первых, приходится вычищать #!/bin/bash из исходников, во-вторых, никто не тестировал результат, вдруг там притаился dlopen("/usr/lib/...").
Мне кажется, это два несвязанных утверждения. Собирать всё подряд Nix вполне можно. Но иногда очень больно и неоправданно. Универсального решения тут, как всегда, нет.
#!/bin/bash приходится вычищать не только в Nix (кстати, Nix это делает сам автомагически!). В FreeBSD, например, bash лежит в /usr/bin. А софт с dlopen() и хардкодом путей лучше просто выкинуть от греха подальше.
Какие преимущества описанный подход дает по сравнению со сборкой в Docker на базе фиксированного образа Alpine/Debian/Ubuntu/etc? (UPD: с зафиксированным срезом репозитария).
Если мы не берём C/C++, у других языков часто бывает очень ооооочень много мелких библиотек, которые в репозитариях традиционных дистрибутивов отсутствуют. В случае Nix всё проще, поскольку derivations генерируются на лету.
Плюс, Nix позволяет проще совмещать сборку компонентов на разных языках. Гораздо приятнее, когда есть небольшая директория с кодом на Nix, чем куча лапши на make, shell и так далее.
Какое лучшее решение, чтобы распространять динамические бинарники, собранные nix из закрытого кода (иначе ответ — через nix же)?
Не очень понял вопрос. Если имеется ввиду, например, наш код, бинарники из которого мы хотим отдать на сторону, то здесь, как и всегда в мире линукса, путь полон боли и страданий :( Docker, AppImage, да хоть RPM с Deb или другие инструменты, но суть в итоге одна: упаковать бинарник с зависимостями и всё вместе поставлять.
Если речь идёт об установке чужого закрытого кода у себя, то Nix позволяет это делать. В Nixpkgs довольно много пакетов, которые ставятся из чужих бинарников напрямую. Patchelf вполне надёжен, если версия библиотек совпадает.
Когда экспериментировал с dockerTools, был удручен тем, что в nixpkgs принято пихать в деривации (пакеты) все, что можно. В результате образ с clang+LLVM, который на базе Debian занимает ~600 МБ, на базе nixpkgs был 1.3 ГБ.
Да, есть такая проблема. О жирных деревьях зависимостей я в следующей статье напишу :)
Я не могу сказать, что видел в Nix какую-то особую идеологию.
Аналогично.
OpenBSD :(
Одна моя знакомая девушка говорила мне: "Пока сам не попробуешь, не узнаешь". Она, правда, имела ввиду совсем другое, но к Nix этот принцип тоже применим.
Ага. Но если, например, проект на двух языках сразу, пакетных менеджеров становится уже два. Я не говорю, что надо всегда использовать Nix. Но в некоторых случаях его использование сильно упрощает жизнь.
Мне кажется, это два несвязанных утверждения. Собирать всё подряд Nix вполне можно. Но иногда очень больно и неоправданно. Универсального решения тут, как всегда, нет.
#!/bin/bash
приходится вычищать не только в Nix (кстати, Nix это делает сам автомагически!). В FreeBSD, например, bash лежит в /usr/bin. А софт сdlopen()
и хардкодом путей лучше просто выкинуть от греха подальше.Если мы не берём C/C++, у других языков часто бывает очень ооооочень много мелких библиотек, которые в репозитариях традиционных дистрибутивов отсутствуют. В случае Nix всё проще, поскольку
derivations
генерируются на лету.Плюс, Nix позволяет проще совмещать сборку компонентов на разных языках. Гораздо приятнее, когда есть небольшая директория с кодом на Nix, чем куча лапши на make, shell и так далее.
Не очень понял вопрос. Если имеется ввиду, например, наш код, бинарники из которого мы хотим отдать на сторону, то здесь, как и всегда в мире линукса, путь полон боли и страданий :( Docker, AppImage, да хоть RPM с Deb или другие инструменты, но суть в итоге одна: упаковать бинарник с зависимостями и всё вместе поставлять.
Если речь идёт об установке чужого закрытого кода у себя, то Nix позволяет это делать. В Nixpkgs довольно много пакетов, которые ставятся из чужих бинарников напрямую. Patchelf вполне надёжен, если версия библиотек совпадает.
Да, есть такая проблема. О жирных деревьях зависимостей я в следующей статье напишу :)