Comments 33
vcpkg install что-угодно, господи. Хватит придумывать велосипеды из костылей.
Мы у себя используем conan
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 не нашел в репозитории. Что с компиляторами тоже непонятно.
Что там с бинарным кешировнием?
Я даже make и cmake не нашел в репозитории. Что с компиляторами тоже непонятно.
Непонятно осознаете ли вы, что сравниваете теплое с мягким.
В смысле сравнивают nix c vcpkgs ? Полностью согласен.
В смысле того, что сравниваются инструменты, скажем так, разных калибров, предназначенные для разных задач.
Например, очень странная претензия в комментарии:
cargo, npm итд в vcpkgs тоже нет, использовать Rust, JS, TS, Python и другие языки без костылей не получится.
Интересно, а в cargo есть Boost или Qt, или тот же npm? Получится ли при разработке на Rust использовать JS, TS и Python без костылей?
В смысле того, что сравниваются инструменты, скажем так, разных калибров, предназначенные для разных задач.
То есть nix с vcpkgs можно сравнивать и это нормально, а если vcpkgs не даёт того, что нужно автору то это уже "теплое с мягким" ?
То есть nix с vcpkgs можно сравнивать и это нормально
Я где-то такое говорил?
Повторю еще раз: nix и vcpkg -- это инструменты разных калибров, предназначенные для разных задач. Поэтому сранивать их (хоть nix с vcpkg, хоть vcpkg с nix) так себе идея. Отсюда и "теплое с мягким".
И когда автор статьи в комментарии говорит о том, что он не может сделать vcpkg install bash, то это свидетельствует о том, что он вообще не понимает что такое vcpkg, зачем он нужен и как используется. Посему такие сравнения с такими примерами выглядят как жалобы на неудобство закручивания гвоздей крестовой отверткой.
Но при этом, начать вы решили с автора статьи, а не с человека, который первым сделал неуместное сравнение, поощряя человека который сделал бессмысленный комментарий в стиле "А почему не [нужное поставить] ?".
Возможно, я уже плохо вижу, но мне кажется, что автор комментария, на который я ответил, и автор статьи -- это один и тот же человек.
Кроме того, вся ветка обсуждения, в которой мы сейчас находимся, началась вовсе не со сравнения, а с того, что типа есть vcpkg и не нужно выдумывать костыли. И все, без сравнений. Сравнения начались как раз автором статьи.
Возможно, я уже плохо вижу, но мне кажется, что автор комментария, на который я ответил, и автор статьи -- это один и тот же человек.
А я про это и говорю.
Сравнения начались как раз автором статьи.
Наверное действительно плохо видите поскольку это не так - https://habr.com/ru/articles/953676/comments/#comment_28922634.
А я про это и говорю.
Простите, что вы говорите? Я в этой ветке обсуждения увидел сравнения только от автора статьи и сравнения эти, скажем так, весьма странные, мягко говоря. Эти сравнения и прокомментировал. И тут вы мне такой "начать вы решили с автора статьи"... Конечно, раз сравнения озвучивать начал автор статьи, то с кого же мне начинать?
Наверное действительно плохо видите поскольку это не так - https://habr.com/ru/articles/953676/comments/#comment_28922634.
Вот этот комментарий полностью:
vcpkg install что-угодно, господи. Хватит придумывать велосипеды из костылей.
Я здесь в упор не вижу утверждений, что vcpkg что-то может, а nix чего-то не может. Или наоборот.
И хотя я не согласен с тов.@Starl1ght, его комментарий я понимаю. Мол, если нужны зависимости для C++ного проекта, то подтянуть их через vcpkg может быть удобнее, чем через nix. Но когда на такое замечание (пусть даже и крайне спорное) отвечают тем, что vcpkg не может установить bash в систему, то это выглядит очень и очень странно. Что, собственно, и вызвало мой комментарий.
Вы хотите продолжить в своем духе или узбагоитесь уже?
И хотя я не согласен с тов.@Starl1ght, его комментарий я понимаю.
Ну то есть просто увидели слово "vcpkg" и сразу приняли сторону.
И хотя я не согласен с тов.@Starl1ght, его комментарий я понимаю. Мол, если нужны зависимости для C++ного проекта, то подтянуть их через vcpkg может быть удобнее, чем через nix.
Вот это уже конструктивное замечание, которое можно было сделать с самого начала. Спасибо!
Ну то есть просто увидели слово "vcpkg" и сразу приняли сторону.
Я не принимал сторону, а увидел, что в какой-то момент пошли:
a) неадекватные сравнения. Пример с vcpkg install bash неадекватен в контексте разговора про vcpkg. Он для таких вещей не предназначался;
b) неадекватные требования к vcpkg: vcpkg решает проблемы только C++ (как cargo решает проблемы только Rust-а, а npm -- только JS). Поэтому странно, что сперва в статье cargo упоминают как образец, а потом в комментариях к vcpkg предъявляют требования, которым тот же упомянутый как образец в статье cargo этим требованиям не соответствует.
И тут уж мне показалось, что в этих наших Интернетиках кто-то сильно не прав.
Почитал всю ветку и так вас и не понял. Что такое теплое и мягкое? Вы пытаетесь что-то сказать, но не можете. Не томите, здесь все свои.
a) неадекватные сравнения. Пример с vcpkg install bash неадекватен в контексте разговора про vcpkg. Он для таких вещей не предназначался;
Сможете объяснить в чем неадекватность и какой контекст разговора. На всякий случай, для контекста "vcpkg install что-угодно".
b) неадекватные требования к vcpkg: vcpkg решает проблемы только C++
В чем неадекватность? Как vcpkg решает проблему работы clang-format который мне нужен для ежедневной разработки на С++?
(как cargo решает проблемы только Rust-а, а npm -- только JS).
Лучше проверять, прежде чем писать. А то может случиться конфуз:
На crates.io живет множество не-Rust проектов. Вы спрашивали про Qt? https://github.com/KDAB/cxx-qt/
npm install -g nushellустановит растовую программу nushell. Опять не "только".pip install cmakeнасколько помню, CMake не на питоне написан.
Поэтому странно, что сперва в статье cargo упоминают как образец, а потом в комментариях к vcpkg предъявляют требования, которым тот же упомянутый как образец в статье cargo этим требованиям не соответствует.
cargo - это образец UX. Некоторые люди на раст пересаживаются только из-за cargo. Подражатель cargo, uv для питона всего лишь год назад появился, а уже дает 10% обращений к PyPI.
nix и vcpkgs - это пакетные менеджеры. Мне как разработчику нужно от них одно: установка зависимостей проекта.
Давно уже не бывает "только C++".
Мне стало интересно, я даже попробовал "vcpkg install что-угодно". Установка все такая же шуточная с клонированием репы и запуском вручную каких-то скриптов, с последующим ручным прописыванием PATH.
Смешно стало с момента когда пакетный менеджер попросил установить зависимости для себя.
Ну ничего, `nix shell nixpkgs#zip` поехали дальше:
Опять вы ошиблись, написав "Непонятно осознаете ли вы, что сравниваете теплое с мягким." к моему "Я даже make и cmake не нашел в репозитории." Не знаете что vcpkg умеет приносить CMake?
Конец простой:
Пакетный менеджер который не может собрать пакет из своего репозитория - это шутка. Но ладно, раз сегодня нам смешно избивать лежачего, поэтому ставим руками autoconf, запускаем:
Окей, еще libtool.
Вот так, всего за полчаса и десяток ручных действий мы смогли собрать программу из репозитория vcpkg.
Конечно, всего этого можно было бы избежать, если установить vcpkg через nix, благо у них есть рецепт со всеми зависимостями прямо в репозитории https://github.com/microsoft/vcpkg/blob/master/shell.nix
"vcpkg install что-угодно, господи"
Почитал всю ветку и так вас и не понял.
Во-первых, не удивительно.
Во-вторых, выяснилось, что не осознаете.
Что такое теплое и мягкое?
Это попытка сравнивать вещи из разных категорий.
Например, когда сравнивают Java и emacs или C# и vim.
Наверное, по каким-то критериям (типа размера дистрибутива или величины порога входа) их можно сравнивать, но его адекватность будет под большим сомнением.
Вы пытаетесь что-то сказать, но не можете
Аминь.
Не томите, здесь все свои.
Тут бы следовало подставить известную цитату из "Брата 1".
Сможете объяснить в чем неадекватность и какой контекст разговора. На всякий случай, для контекста "vcpkg install что-угодно".
Для людей, которые знакомы с vcpkg выражение "vcpkg install что-угодно" означает установку библиотек из репозитория vcpkg. Не более того. Вы же в своей статье писали про то, что вам для проекта нужен nlohman_json. Вот nlohman_json попадает в скоуп vcpkg, а bash -- нет.
Это то же самое, как пенять Nix-у, что через него нельзя под Windows установить Visual Studio.
В чем неадекватность?
Во-первых, в стравнении.
Во-вторых, в нежелании читать и думать. Или в неспособность, тут пока рано делать выводы.
Как vcpkg решает проблему работы clang-format который мне нужен для ежедневной разработки на С++?
А он их и не решает. Он подтягивает библиотеки, которые нужны для компиляции и линковки вашего С++ного проекта. А clang-format таковой библиотекой не нуждается.
Лучше проверять, прежде чем писать. А то может случиться конфуз:
На crates.io живет множество не-Rust проектов. Вы спрашивали про Qt? https://github.com/KDAB/cxx-qt/
Ну и где там нужный вам nlohman_json? Что ж вы, если вам нужно писать на C++ и вам так нравится cargo, не пользуетсь cargo для управления зависимостями?
То, что менеджерам зависимостей для других языков приходится таскать наработки из мира C и C++ не удивительно. Если на условном Rust-е все никак не могут написать свой Qt, то остается только паразитировать на уже готовом Qt и делать так, чтобы менеджер зависимостей мог этот Qt подтянуть к проекту на условном Rust-е (или Python-е).
А вот в мире С и С++ пока насрать на то, что делается на условном Rust-е, т.к. влияние этого пока что ничтожно.
nix и vcpkgs - это пакетные менеджеры. Мне как разработчику нужно от них одно: установка зависимостей проекта.
Вот как раз из-за того, что вы причисляете vcpkg в категорию "пакетного менеджера" (да еще наделяя термин "пакетный менеджер" смыслом из Unix-ного мира) и возникает проблема. vcpkg не является таковым в том смысле, который вам нужен.
И, что характерно, таковым он и не задумывался. По крайней мере, пока.
Кстати, называется vcpkg именно как vcpkg, а не vcpkgs. Так что вы и здесь демонстрируете незнание материала.
Давно уже не бывает "только C++".
Да что вы говорите... А мужики-то и не знают.
Опять вы ошиблись, написав "Непонятно осознаете ли вы, что сравниваете теплое с мягким." к моему "Я даже make и cmake не нашел в репозитории."
Я не ошибся.
Не знаете что vcpkg умеет приносить CMake?
Знаю. Под Windows, например, он может и Perl, и MSYS2 с bash-ем поставить. Но только для своих нужд, чтобы собрать из исходников библиотеку, которая вам потребовалась. Пользователю нет доступа к этим инструментам. Т.е. для пользователя он CMake "приносить" таки не умеет.
Кстати говоря, если работать с vcpkg в режиме манифеста и через CMake-овский TOOLCHAIN-файл, то никакие PATH вручную модифицировать не нужно.
CMake все еще лучшее что есть для сборки в С++?
А оно кроссплатформенное, на мак и виндовс эта схема будет так же работать?
А оно умеет кросс-компиляцию из коробки, без напильника?
Я бы ответил на ваш вопрос "нет", тот 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
Очень интересное решение, особенно для серверов. Декларативный подход Nix - гуд.
А как зафиксировать версии компиляторов-то? Для герметичной сборки вроде как необходимость.
Грубо говоря они зафиксированы строкой "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 на данный момент - комлияторы, библиотеки и даже версия баша.
Так, а если скажем хочется какой-нибудь gcc 4.9.X, но при этом в составе иметь какой-нибудь пакет под rust 1.92, то как все это стыкуется? Каждый срез nixpkgs содержит весь срез прошлых версий?
В inputs указывается несколько срезов nixpkgs с нужными версиями (в статье срез один и назван nixpkgs, а добавится nixpkgs-2205 какой-нибудь). Каждый элемент outputs может использовать нужный срез и даже составлять сборочную среду из дериваций (пакетов), входящих в разные срезы. Фишка Nix в том, что они не будут конфликтовать, например, GCC 4.9.x и CMake могут без проблем пользоваться разными версиями libc. Похоже на установку в /opt с rpath, только всё автоматически.
Вот вопрос очень правильный и очень сложный
Каждый срез 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 файлом.
gcc 4.9 это я конечно от балды сказал, подсмотрев какие версии compiler explorer поддерживает. Речь скорее за ситуацию, когда зависимости требуют одновременно и несколько древние (но присутствовавшие и ещё не выпиленные) и свежие зависимости и все, которых могло и не существовать на момент существования прошлых зависимостей. Собственно обратная ситуация тоже возможна - например debian по-умолчанию использует gcc 12 и clang 14, а мы например хотим собирать код С++20 компиляторами с их стабильной поддержкой - то бишь gcc не старше 14 и clang не ранее 19. trunk версии там ещё выше, естественнно.
nixpkgs-legacy
это какое-то наше произвольное имя, которое мы задаём, так?
nix develop
вот этот момент кстати тоже несколько непонятен. Мне казалось, что мы где-то явно указываем, что входит в окружение develop и что помимо develop есть ещё другие варианты, но в примере вашего скрипта develop нигде явно не упоминался.
gcc 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.
Управляем зависимостями Cи и C++ через Nix