Я использую Nix уже не на первой своей работе. Это универсальный инструмент, который может сильно облегчить жизнь разработчика, автоматизируя управление средой разработки.
Сегодня я хотел бы подробнее разобрать самую полезную часть Nix — управление пакетами из репозитория nixpkgs.
Я использовал и использую разные языки. В Rust есть прекрасный пакетный менеджер cargo и инсталлятор rustup, для JavaScript — npm. Мне также нравится conda в мире Python.
Мне всегда не хватало чего-то подобного для проектов на Си и C++. Пакетные менеджеры для этих языков часто оставляют желать лучшего. Даже если они работают, в их репозиториях может не быть нужных библиотек. Даже если вроде всё работает хорошо, может оказаться, что для работы бинарного кэширования нужно прилагать усилия, а когда это что-то вроде разных версий Qt — собирать всё на машине разработчика неприятно.
Я хотел, чтобы инструмент из коробки давал максимум без дополнительной настройки.
Поэтому я расскажу, как использовать Nix в качестве пакетного менеджера для Си и C++.
Почему именно Nix?
В nixpkgs — репозитории с пакетами для Nix — более 100 тысяч рецептов сборки разных программ и библиотек.
Большая часть из них — на Си и C++. Это значит, что любая популярная библиотека или утилита может уже быть описана, и для её подключения достаточно лишь добавить зависимость.
Работа с зависимостями — головная боль в мире C и C++; Nix решает её почти полностью, позволяя сфокусироваться на том, что важно — на написании продуктового кода.
Nix не привязан к конкретному языку: компиляторы, линтеры, различные тулзы почти наверняка уже есть в nixpkgs, так что добавление нового языка — просто добавление зависимости.
Например, я писал Bash-скрипт и “собирал” его с помощью Nix, чтобы гарантировать наличие утилит, которых может не быть в чистой установке Ubuntu. Даже у простых скриптов есть зависимости: Nix позволяет описать, например, jq, и быть уверенным, что в PATH будет нужная версия этого инструмента.
Контейнеры разработчика
Компании часто используют Docker или подобные контейнеры для среды разработки. Это работает, но в большинстве случаев управление зависимостями не требует контейнеров. Пакетные менеджеры языков справляются на простых файлах.
Контейнеризация — дополнительная сложность. Она приносит лишний слой абстракции, который может мешать: нужно настраивать, синхронизировать, возможны различия локально / в CI.
Новичкам Docker может мешать из-за дополнительных настроек и нужды понимать больше инфраструктуры.
Лично я предпочитаю не использовать контейнеры для разработки. Всегда просто брал и устанавливал глобально зависимости из их рецепта сборки.
Опыт разработчика
При внедрении нового инструмента часто не хочется менять существующую систему сборки (GNU Make, CMake и др.).
Иногда вы не контролируете репозиторий пакета, который надо собрать, и не можете его модифицировать.
Nix особенно хорош как внешний менеджер пакетов к уже существующей системе сборки. Хорошо работающие манифесты для систем сборки - это большой плюс в "никсификации" проекта.
Интеграция с IDE
Ещё одна боль в мире Си/C++ — поддержка со стороны IDE.
Редактор по умолчанию не знает, какие зависимости у проекта, и загружает только системные заголовки (например,
/usr/includeи др.).Если библиотека собрана вручную, может потребоваться ручное прописывание
Include path.
Я бы сказал что даже с поддержкой сборки из консоли у плюсов проблемы. Если проект на JavaScript или Rust можно собрать всегда одной и то же командой, которая по необходимости установит нужную версию компилятора, библиотек, выполнит дополнительные конфигурационные скрипты, выставит переменные окружения... то у нас может быть есть скрипт build.sh. Со своими зависимостями.
Сценарий с заголовками в /usr/include тоже легко ломается в момент, когда вы работаете над несколькими проектами, которым требуются разные версии библиотек.
Сегодня мы решим все эти проблемы с помощью Nix.
Цели
Создать два проекта на Си и C++: с библиотеками для работы с JSON —
cJSONдля Си иnlohmann_jsonдля C++.Использовать CMake как систему сборки, в дополнение к Nix.
Все зависимости и рабочее окружение описаны в репозитории: для воспроизведения нужен только Nix.
Разработка в VSCode с работающим IntelliSense и плагином CMake.
Простота конфигурации, максимальная автоматизация и воспроизводимость.
Глоссарий
Рабочее пространство (workspace) — корень репозитория, то, что вы открываете в IDE (например, VSCode).
Проект / пакет — часть репозитория, которую можно собрать и получить полезный самодостаточный артефакт (например, исполняемый файл).
Необходимое
Nix с включёнными flakes.
Рекомендую использовать этот инсталлятор:
curl -fsSL https://install.determinate.systems/nix | sh -s -- install
Nix можно установить разными способами, в том числе и без root-прав в системе.
Если следующая команда отрабатывает без ошибок, все отлично:
❯ nix flake --version
nix (Nix) 2.28.3
Статья ориентирована на версию Nix 2.28.
direnv
direnv — утилита для управления средой в командной оболочке. Хотя напрямую не связана с Nix, она часто используется в связке.
Теперь, после того как у вас есть Nix, программы можно устанавливать из nixpkgs:
nix profile install nixpkgs#direnv
# Если используете bash, добавьте хук или прочитайте в руководстве
# к direnv как добавить его в вашу оболочку.
echo 'eval "$(direnv hook bash)"' >> ~/.bashrc
Расширения VSCode
Чтобы vscode использовал direnv необходимо одноименное расширение direnv.
Для Nix тоже есть расширения для VSCode, с поддержкой Language Server Protocol. Для простоты мы не будем рассматривать это в этой статье.
Структура репозитория
Описываем репозиторий находится здесь.
.
├── CMakeLists.txt
├── README.md
├── flake.lock
├── flake.nix
└── src
├── c
│ ├── CMakeLists.txt
│ └── main.c
└── cc
├── CMakeLists.txt
└── main.cc
Корневой CMakeLists.txt содержит:
cmake_minimum_required(VERSION 3.10)
project(hello_json)
add_subdirectory(src/c)
add_subdirectory(src/cc)
Проект на C: hello-json-c
Начнем с описателя CMakeLists.txt:
find_package(cJSON REQUIRED)
add_executable(hello-json-c main.c)
target_link_libraries(hello-json-c PRIVATE cjson)
install(TARGETS hello-json-c DESTINATION bin)
Хотя find_package() ищет пакет в "системе" но к моменту когда вы или Nix запустит команду сборки, он установит необходимые пути поиска и это сработает.
Nix и другие пакетные менеджеры определяют содержание окончательного пакета по тому, что записано в результирующую (install) директорию на фазе установки. Поэтому нам необходимо описать эту фазу. Если этого не сделать, сборка через Nix не будет работать. Ручная сборка выполнением cmake --build будет работать всегда.
Структура директории с результатом должна удовлетворять FHS, поэтому мы пишем в /bin.
#include <stdio.h>
#include <stdlib.h>
#include <cjson/cJSON.h>
int main(void)
{
cJSON *root = cJSON_CreateObject();
cJSON_AddStringToObject(root, "message", "Hello, world from C and cJSON!");
char *json_str = cJSON_Print(root);
printf("%s\n", json_str);
cJSON_Delete(root);
free(json_str);
return EXIT_SUCCESS;
}
Здесь все просто: создаем JSON из объекта с полем message и текстом "Hello, world from C and cJSON!".
Проект на C++: hello-json-cc
CMakeLists.txt не сильно отличается:
set(CMAKE_CXX_STANDARD 17)
find_package(nlohmann_json REQUIRED)
add_executable(hello-json-cpp main.cc)
target_link_libraries(hello-json-cpp PRIVATE nlohmann_json::nlohmann_json)
install(TARGETS hello-json-cpp DESTINATION bin)
#include <iostream>
#include <nlohmann/json.hpp>
int main()
{
nlohmann::json hello;
hello["message"] = "Hello, world from C++ and nlohmann::json!";
std::cout << hello.dump(4) << std::endl;
assert(hello.count("message") == 1);
return 0;
}
У нас есть исходные файлы, рецепты их сборки на CMake, теперь перейдем к описанию зависимостей на языке Nix.
flake.nix
Здесь мы опишем два пакета:
hello-json-c = pkgs.stdenv.mkDerivation {
pname = "hello-json-c";
version = "0.1.0";
src = ./src/c;
nativeBuildInputs = [
pkgs.cjson
pkgs.cmake
];
};
Называем проект на Си hello-json-c, указываем в качестве зависимостей сборки cjson и cmake. Указываем путь до файлов исходного кода ./src/c.
Пакет для hello-json-cc отличается лишь одной зависимостью:
hello-json-cc = pkgs.stdenv.mkDerivation {
pname = "hello-json-cc";
version = "0.1.0";
src = ./src/cc;
nativeBuildInputs = [
pkgs.cmake
pkgs.nlohmann_json
];
};
mkDerivation здесь - это функция, генерирующая скрипт сборки проектов на основе распространенных инструментов сборки, вроде GNU Make, CMake и множества других. Подробнее среда сборки описана в руководстве по nixpkgs. Ради снижения количества бойлерплейта, сборочный скрипт адаптируется под зависимости сборки, и в нашем случае будет использовать CMake вместо GNU Make. Если вы подключите pkgs.ninja, то он также автоматически будет использован.
Нам также понадобится среда для разработки, состоящая из зависимостей всех пакетов:
devShells.${system}.default = pkgs.mkShell {
name = "hello-json";
inputsFrom = [
hello-json-c
hello-json-cc
];
};
Полное содержание итогового файла flake.nix:
{
description = "Parse JSON in C and C++";
inputs = {
nixpkgs.url = "github:nixos/nixpkgs/nixos-25.05";
};
outputs =
{ self, nixpkgs }:
let
system = "x86_64-linux";
pkgs = nixpkgs.legacyPackages.${system};
hello-json-c = pkgs.stdenv.mkDerivation {
pname = "hello-json-c";
version = "0.1.0";
src = ./src/c;
nativeBuildInputs = [
pkgs.cjson
pkgs.cmake
];
};
hello-json-cc = pkgs.stdenv.mkDerivation {
pname = "hello-json-cc";
version = "0.1.0";
src = ./src/cc;
nativeBuildInputs = [
pkgs.cmake
pkgs.nlohmann_json
];
};
in
{
packages.${system} = { inherit hello-json-c hello-json-cc; };
devShells.${system}.default = pkgs.mkShell {
name = "hello-json";
inputsFrom = [
hello-json-c
hello-json-cc
];
};
};
}
Сделайте git commit, так как Nix игнорирует файлы, которые не управляются Git.
Оболочка разработчика
На этом этапе наше рабочее пространство должно начать работать. Для того чтобы открыть оболочку разработчика, наберите:
nix develop
В ней будет cmake а также CMAKE_INCLUDE_PATH с путями до cjson и nlohmann_json. Поэтому следующие команды должны завершиться успешно:
cmake -S . -B build
cmake --build build --target hello-json-c
cmake --build build --target hello-json-cc
❯ ./build/src/c/hello-json-c
{
"message": "Hello, world from C and cJSON!"
}
❯ ./build/src/cc/hello-json-cc
{
"message": "Hello, world from C++ and nlohmann::json!"
}
Выйти из оболочки можно нажатием Ctrl+D.
direnv
Можно автоматизировать загрузку и выгрузку оболочки разработчика.
Создайте файл .envrc:
use flake
Чтобы разрешить применение среды из репозитория наберите
direnv allow
в директории с репозиторием. Теперь терминал с текущей директории внутри репозитория всегда будет иметь нужные разработчику инструменты.
Visual Studio Code
Достаточно разрешить расширению direnv загрузку профиля:
И перезагрузить окно:
Теперь CMake увидит компилятор:
И цели сборки:
Если открыть файл исходного кода, то видно что заголовки загружены:
Причем при переходе к определению cJSON_Print() открывается файл из /nix/store:
Обратите внимание, что кроме установки расширения direnv и разрешения его работы, мы больше никак не конфигурировали VSCode для работы с проектом. Конфигурация описана в репозитории в Nix файлах и одинакова у всех разработчиков. Все работает работает сразу после того как вы склонировали репозиторий.
Сборка и запуск через Nix
Мы описали два пакета. Если вы их не разрабатываете, то скорее всего они нужны вам лишь в готовом виде и ручной процесс сборки вас не интересует. В этом случае вам лучше использовать сам Nix для сборки и запуска:
❯ nix run .#hello-json-c
{
"message": "Hello, world from C and cJSON!"
}
❯ nix run .#hello-json-cc
{
"message": "Hello, world from C++ and nlohmann::json!"
}
На самом деле, вам не нужно даже клонировать репозиторий, для того чтобы строить и запускать артефакты из него! Это сработает:
❯ nix run git+https://gitverse.ru/nix-store/hello-json#hello-json-c
{
"message": "Hello, world from C and cJSON!"
}
❯ nix run git+https://gitverse.ru/nix-store/hello-json#hello-json-cc
{
"message": "Hello, world from C++ and nlohmann::json!"
}
Итоги
Мы создали монорепозиторий с двумя проектами: hello-json-c и hello-json-cc. Описали их сборку на CMake, чтобы опыт при использовании Nix не отличался от классического. Зависимости описаны в flake.nix, конкретные версии - в flake.lock. Они одинаково разрешаются и используются для: финальной сборки, в CI, оболочке разработчика и IDE.
Наша IDE полнофункционально работает из коробки, достаточно лишь склонировать репозиторий и разрешить работу direnv.
В идеале Nix вообще незаметен для рядового разработчика. Nix используется лишь для работы с зависимостями, благодаря чему CMake и IDE всегда находят в окружении то, что им нужно.
Комментарии (30)
Sazonov
05.10.2025 23:14А оно умеет кросс-компиляцию из коробки, без напильника?
maquefel
05.10.2025 23:14Я бы ответил на ваш вопрос "нет", тот flake.nix в статье так просто не кросскомпилируешь, его необходимо немного переписать на мой взгляд, так как там уже закреплёна система. Ему надо либо прописывать каждый кросс либо добавлять к существующим пакетам nixpkgs (это можно сделать не меняя проект). И я бы не назвал эти манипуляции "без напильника".
Тогда будет работать что-то вроде:
# nix build .#legacyPackages.x86_64-linux.pkgsCross.aarch64-multiplatform.hello-json-cКак это работает сейчас с пакетом hello:
# nix build nixpkgs#legacyPackages.x86_64-linux.pkgsCross.aarch64-multiplatform.hello # file result/bin/hello result/bin/hello: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /nix/store/x35a5fq7s2m0d26b2c4mzhijqmk71axr-glibc-aarch64-unknown-linux-gnu-2.40-66/lib/ld-linux-aarch64.so.1, for GNU/Linux 3.10.0, not stripped
HarrierDuBois
05.10.2025 23:14Очень интересное решение, особенно для серверов. Декларативный подход Nix - гуд.
domix32
05.10.2025 23:14А как зафиксировать версии компиляторов-то? Для герметичной сборки вроде как необходимость.
maquefel
05.10.2025 23:14Грубо говоря они зафиксированы строкой "nixpkgs.url = "github:nixos/nixpkgs/nixos-25.05";" и потом это фиксируется в flake.lock:
"locked": { "lastModified": 1759580034, "narHash": "sha256-YWo57PL7mGZU7D4WeKFMiW4ex/O6ZolUS6UNBHTZfkI=", "owner": "nixos", "repo": "nixpkgs", "rev": "3bcc93c5f7a4b30335d31f21e2f1281cba68c318", "type": "github" },То есть фиксируется всё что находится в nixpkgs на данный момент - комлияторы, библиотеки и даже версия баша.
domix32
05.10.2025 23:14Так, а если скажем хочется какой-нибудь gcc 4.9.X, но при этом в составе иметь какой-нибудь пакет под rust 1.92, то как все это стыкуется? Каждый срез nixpkgs содержит весь срез прошлых версий?
kozlyuk
05.10.2025 23:14В inputs указывается несколько срезов nixpkgs с нужными версиями (в статье срез один и назван nixpkgs, а добавится nixpkgs-2205 какой-нибудь). Каждый элемент outputs может использовать нужный срез и даже составлять сборочную среду из дериваций (пакетов), входящих в разные срезы. Фишка Nix в том, что они не будут конфликтовать, например, GCC 4.9.x и CMake могут без проблем пользоваться разными версиями libc. Похоже на установку в /opt с rpath, только всё автоматически.
maquefel
05.10.2025 23:14Вот вопрос очень правильный и очень сложный
Каждый срез nixpkgs содержит весь срез прошлых версий?
Нет не содержит - удаляются постепенно.
Тогда в большинстве случаев вы берете какую-нибудь версию nixpkgs и eсли как в вашем примере версия gcc 4.9.X которой нету pkgs/development/compilers/gcc/versions.nix:
commit 88950412bcdc0fde3811444024b46a79ffc56068 Author: Sergei Trofimovich <slyich@gmail.com> Date: Wed Sep 11 21:57:54 2024 +0100 gcc49, gcc49Stdenv, gfortran49: remove old implementation gcc-4.9.4 was released in Aug 3, 2016, 8 years ago. It's a branch that went out of support years ago. Numerous bugs never get backported to this version. Let's remove it.Вам придётся её добавлять хотя бы для своего пакета (я уверен, что с 4.9 gcc 25.05 мы просто не соберём), каким-то образом:
добавить input для 24.10 (это до удаления):
nixpkgs-legacy.url = "github:NixOS/nixpkgs/nixos-24.10"; [...] pkgs-legacy = import nixpkgs-legacy { inherit system; };И тогда можно будет использовать pkgs-legacy.gcc49Stdenv
вернуть то что удалили (тогда придётся собирать его заново из исходников);
подсунуть для конкретного вашего пакета прекомпилированный компилятор (а можно и пропиетарный);
Тогда всё это будет однозначно зафиксированно фашим flake файлом.
domix32
05.10.2025 23:14gcc 4.9 это я конечно от балды сказал, подсмотрев какие версии compiler explorer поддерживает. Речь скорее за ситуацию, когда зависимости требуют одновременно и несколько древние (но присутствовавшие и ещё не выпиленные) и свежие зависимости и все, которых могло и не существовать на момент существования прошлых зависимостей. Собственно обратная ситуация тоже возможна - например debian по-умолчанию использует gcc 12 и clang 14, а мы например хотим собирать код С++20 компиляторами с их стабильной поддержкой - то бишь gcc не старше 14 и clang не ранее 19. trunk версии там ещё выше, естественнно.
nixpkgs-legacyэто какое-то наше произвольное имя, которое мы задаём, так?
nix developвот этот момент кстати тоже несколько непонятен. Мне казалось, что мы где-то явно указываем, что входит в окружение develop и что помимо develop есть ещё другие варианты, но в примере вашего скрипта develop нигде явно не упоминался.
maquefel
05.10.2025 23:14gcc 4.9 это я конечно от балды сказал, подсмотрев какие версии compiler explorer поддерживает. Речь скорее за ситуацию, когда зависимости требуют одновременно и несколько древние (но присутствовавшие и ещё не выпиленные) и свежие зависимости и все, которых могло и не существовать на момент существования прошлых зависимостей.
Это можно, это будет встроено в общую парадигму Nix и делается средствами Nix (я не буду говорить, что это будет легко), иммутабельно, воспроизводимо (тут Nix не врёт), но вы за это заплатите:
такая "старая" зависимость потянет за собой все старые версии из предыдущего среза, если конечно нет пересечений множеств старого и нового среза (скорей всего их не будет) и в итоге вы будете иметь два rootfs пересекающихся в данной точке;
двойной ценой за два экземпляра nixpkgs - хэши и зависимости будут считаться отдельно;
Собственно обратная ситуация тоже возможна - например debian по-умолчанию использует gcc 12 и clang 14, а мы например хотим собирать код С++20 компиляторами с их стабильной поддержкой - то бишь gcc не старше 14 и clang не ранее 19. trunk версии там ещё выше, естественнно.
Тоже можно те же самые преимкщества, но возможно придётся прописывать все зависимости - менять версию и проверять это тоже работа и немалая.
это какое-то наше произвольное имя, которое мы задаём, так?
Абсолютно верно.
вот этот момент кстати тоже несколько непонятен. Мне казалось, что мы где-то явно указываем, что входит в окружение develop и что помимо develop есть ещё другие варианты, но в примере вашего скрипта develop нигде явно не упоминался.
Я не автор, просто мимо пробегал, а тут так интересно (не считая первого комментария разумеется).
Вот тут интересная вещь, дело в том что в старой версии есть такая вещь как nix-shell, которой нет в "nix flakes" которую использует автор статьи. В статье явно прописан "devShells.${system}.default", который как "all" для Makefile и будет вызван для "nix develop", который ничо иное как "nix develop .#devShells.x86_64-linux.default" или "nix develop .#" собственно он его берет из flake.nix:
# nix flake show git+file:///root/hello-json?ref=refs/heads/master&rev=772d2bd186214ce49c516eff7f3eb1d9265e158c ├───devShells │ └───x86_64-linux │ └───default: development environment 'hello-json' └───packages └───x86_64-linux ├───hello-json-c: package 'hello-json-c-0.1.0' └───hello-json-cc: package 'hello-json-cc-0.1.0'Далее это именно прописанный shell, он нужен, чтобы мы знали сразу о hello-json-c и hello-json-cc - за это отвечает inputsFrom. Мы могли бы просто вызвать "nix develop .#packages.x86_64-linux.hello-json-c" и получили бы окружение для hello-json-c без знания о hello-json-cс (если бы у нас не был общий cmake) но точно без зависимости nlohmann_json, если у нас именно полноценный NixOS, а не просто утилита nix.
Starl1ght
vcpkg install что-угодно, господи. Хватит придумывать велосипеды из костылей.
DancingOnWater
Мы у себя используем conan
Gordon01 Автор
vcpkgs:
initial release: 2016
projects total: 2 471
nix:
initial release: June 15, 2003
projects total: 107 989
Кто еще велосипед))
vcpkg, conan - это все запорожцы в мире пакетных менеджеров. Как-то они работают, умеют делать минимальную работу, но шаг влево-вправо и нужен уже другой тулинг.
vcpkg install bash- упс, уже не работает. Даже воспроизводимый bash-скрипт в репозиторий уже не положишь.vcpkg install mdbook- упс, HTML документацию из Markdown без костылей вы уже не сгенерируете.cargo, npm итд в vcpkgs тоже нет, использовать Rust, JS, TS, Python и другие языки без костылей не получится.
Хотите указать версию boost? Это уже не так просто https://learn.microsoft.com/en-us/vcpkg/users/examples/modify-baseline-to-pin-old-boost
Используете QEMU? Его тоже нет в vcpkgs, а ведь это стандартный тулинг разработчика и тестировщика.
Я даже make и cmake не нашел в репозитории. Что с компиляторами тоже непонятно.
Что там с бинарным кешировнием?
eao197
Непонятно осознаете ли вы, что сравниваете теплое с мягким.
maquefel
В смысле сравнивают nix c vcpkgs ? Полностью согласен.
eao197
В смысле того, что сравниваются инструменты, скажем так, разных калибров, предназначенные для разных задач.
Например, очень странная претензия в комментарии:
Интересно, а в cargo есть Boost или Qt, или тот же npm? Получится ли при разработке на Rust использовать JS, TS и Python без костылей?
maquefel
То есть nix с vcpkgs можно сравнивать и это нормально, а если vcpkgs не даёт того, что нужно автору то это уже "теплое с мягким" ?
eao197
Я где-то такое говорил?
Повторю еще раз: nix и vcpkg -- это инструменты разных калибров, предназначенные для разных задач. Поэтому сранивать их (хоть nix с vcpkg, хоть vcpkg с nix) так себе идея. Отсюда и "теплое с мягким".
И когда автор статьи в комментарии говорит о том, что он не может сделать
vcpkg install bash, то это свидетельствует о том, что он вообще не понимает что такое vcpkg, зачем он нужен и как используется. Посему такие сравнения с такими примерами выглядят как жалобы на неудобство закручивания гвоздей крестовой отверткой.maquefel
Но при этом, начать вы решили с автора статьи, а не с человека, который первым сделал неуместное сравнение, поощряя человека который сделал бессмысленный комментарий в стиле "А почему не [нужное поставить] ?".
eao197
Возможно, я уже плохо вижу, но мне кажется, что автор комментария, на который я ответил, и автор статьи -- это один и тот же человек.
Кроме того, вся ветка обсуждения, в которой мы сейчас находимся, началась вовсе не со сравнения, а с того, что типа есть vcpkg и не нужно выдумывать костыли. И все, без сравнений. Сравнения начались как раз автором статьи.
maquefel
А я про это и говорю.
Наверное действительно плохо видите поскольку это не так - https://habr.com/ru/articles/953676/comments/#comment_28922634.
eao197
Простите, что вы говорите? Я в этой ветке обсуждения увидел сравнения только от автора статьи и сравнения эти, скажем так, весьма странные, мягко говоря. Эти сравнения и прокомментировал. И тут вы мне такой "начать вы решили с автора статьи"... Конечно, раз сравнения озвучивать начал автор статьи, то с кого же мне начинать?
Вот этот комментарий полностью:
Я здесь в упор не вижу утверждений, что vcpkg что-то может, а nix чего-то не может. Или наоборот.
И хотя я не согласен с тов.@Starl1ght, его комментарий я понимаю. Мол, если нужны зависимости для C++ного проекта, то подтянуть их через vcpkg может быть удобнее, чем через nix. Но когда на такое замечание (пусть даже и крайне спорное) отвечают тем, что vcpkg не может установить bash в систему, то это выглядит очень и очень странно. Что, собственно, и вызвало мой комментарий.
Вы хотите продолжить в своем духе или узбагоитесь уже?
maquefel
Ну то есть просто увидели слово "vcpkg" и сразу приняли сторону.
Вот это уже конструктивное замечание, которое можно было сделать с самого начала. Спасибо!
eao197
Я не принимал сторону, а увидел, что в какой-то момент пошли:
a) неадекватные сравнения. Пример с
vcpkg install bashнеадекватен в контексте разговора про vcpkg. Он для таких вещей не предназначался;b) неадекватные требования к vcpkg: vcpkg решает проблемы только C++ (как cargo решает проблемы только Rust-а, а npm -- только JS). Поэтому странно, что сперва в статье cargo упоминают как образец, а потом в комментариях к vcpkg предъявляют требования, которым тот же упомянутый как образец в статье cargo этим требованиям не соответствует.
И тут уж мне показалось, что в этих наших Интернетиках кто-то сильно не прав.