# Установить пакет {#root} @status:doc/work @audience:user [p01] Вы нашли пакет, которому должен следовать ваш проект. Эта страница добавляет его в проект, записывает точную версию и показывает, как проверить, что агент теперь будет его читать. [p02] ```prompt Установи пакет org.vibevm.world/wal в проект VibeVM в текущей папке, прими план и скажи мне, какая версия записана и что агент прочитает из неё в начале сессии. ``` - needs: навык vibevm, установленный у вашего агента; проект с `vibe.toml` в текущей папке; доступ по сети к реестрам проекта или пакет, уже лежащий в машинном хранилище outcome: `vibe.toml` перечисляет пакет среди требований, `vibe.lock` закрепляет одну версию с отпечатком содержимого, дерево пакета лежит под `vibevm/vibedeps/`, а `vibe tree` показывает его стартовый фрагмент в списке чтения - assert: `grep -q "org.vibevm.world/wal" vibe.lock` - assert: `vibe check --quiet` ## Что происходит {#what-happens} [p03] Агент выполняет `vibe install org.vibevm.world/wal`. vibe обходит [реестры](../glossary/index.xml#registry) проекта по порядку и спрашивает у первого, который знает пакет, его версии; без ограничения он берёт новейший стабильный выпуск. Он разрешает собственные зависимости пакета вместе с остальным графом проекта, скачивает всё, чего ещё нет в машинном [хранилище](../glossary/index.xml#store), и сверяет каждый [отпечаток](../glossary/index.xml#fingerprint). Потом печатает план: какие пакеты будут добавлены в каких версиях и какие файлы изменятся. Пока вы не подтвердили, ничего не записывается. После подтверждения vibe копирует пакеты в `vibevm/vibedeps/`, записывает требование в `vibe.toml` и пины в `vibe.lock` и пересобирает стартовые файлы. Затем агент запускает `vibe tree`, чтобы показать вам новый список чтения. > [p04] **Resolution** — the depsolver: read every node's `[requires]`, pick one version per package. It **must stay unified** (one `vibe.lock`, one version per package across the workspace — the diamond problem; PROP-007 §2.4). It cannot be computed per-subtree. But it *can be skipped entirely* when its inputs are unchanged (§2.2). > > ## Руками {#by-hand} [p05] 1. Установите по [координате](../glossary/index.xml#coordinate). Добавьте `@` и ограничение, чтобы попросить диапазон или точную версию: [p06] Example `install` is copied from the source page at projection time. [p07] 2. Подтвердите план, когда спросят. `--assume-yes` отвечает «да» за скрипты и агентов. [p08] 3. Проверьте, что записано и что агент будет читать: [p09] Example `list` is copied from the source page at projection time. [p10] Example `tree` is copied from the source page at projection time. ## Как попросить версию {#constraints} [p11] `vibe install org.vibevm.world/wal@^1.0` принимает любую 1.x; `@=1.0.0` — ровно одну; `--exact` записывает разрешённую версию в [манифест](../glossary/index.xml#manifest) точным пином вместо диапазона. Манифест хранит ограничение, о котором вы просили; [лок-файл](../glossary/index.xml#lock-file) хранит версию, которую вы получили. > [p12] `flow:wal@^0.3` → semver range. > > [p13] Префикс вида, как в `flow:org.vibevm.world/wal`, необязателен; когда он есть, vibe его проверяет: если пакет оказывается другого вида, установка останавливается. > [p14] resolved exactly; **kind validated against the manifest** > > ## После клонирования проекта {#after-a-clone} [p15] `vibe install` без имён пакетов ставит то, что манифест уже требует, в версиях, которые закрепил лок-файл. Когда ни манифест, ни лок не менялись с прошлой установки, vibe даже не запускает резолвер: лок-файл и есть ответ, а команда только проверяет, что дерево ему соответствует. > [p16] With the freshness check, **`vibe install` becomes lockfile-respecting**: unchanged `[requires]` ⇒ the locked versions are honoured verbatim. > > ## Особые случаи и правила {#edge-cases} [p17] Установка пакета по имени разрешает весь граф заново, но каждая зависимость, которой изменение не касается, сохраняет закреплённую версию; только настоящий конфликт запускает полный пересчёт. > [p18] When `[requires]` *has* changed, resolution runs, but **holds the lock for every dependency the change did not touch** (§5.3): each registry-resolved root the lock still satisfies is pinned to its locked version, so the re-resolve never drifts an untouched dependency — only the changed one and its subtree move. > > [p19] Пакет может объявить скрипт, который выполняется после его установки. Установить пакет — значит согласиться его запустить; скрипт работает внутри собственной папки пакета, и его последствия не отслеживаются. Прочитайте манифест пакета, которому не доверяете, прежде чем ставить его. > [p20] **Current law.** Installing the package is the consent to run its declared > hooks. There is no `[hooks].allowed_groups`, first-run prompt, or > `--allow-hooks` permission layer. Safety is the PROP-054 observability model: > the manifest is statically inspectable, selected contributions are narrated, > and durable run evidence identifies what ran and which package supplied it. > > [p21] Уже установленный пакет не ставится второй раз: vibe говорит об этом и указывает на `vibe update`. [p22] Публичный реестр, который на отсутствующий пакет отвечает ошибкой аутентификации, обходится стороной и не считается сбоем; добавьте `--auth-required` в скрипт, который должен заметить, что приватный реестр лежит. [p23] Пакет, который приносит инструменты, записывается при установке и собирается по требованию: `vibe bin build` компилирует названные инструменты или все сразу из точно установленного пакета, а `vibe bin exec ` разрешает инструмент через лок-файл проекта до его папки и запускает, при необходимости сначала собрав. Установить пакет — значит согласиться на сборку, и vibe рассказывает, что собирается компилировать. Без сети сборка, которой нужны крейты из сети, падает так же, как падает Cargo, с ручным рецептом в подсказке. Когда вашему коду нужен поставленный крейт, ссылайтесь на него путём в папку пакета и держите `vibevm/vibedeps/` вне своего Cargo-workspace, потому что папка не может принадлежать двум workspace сразу. > [p24] After materialising a slot whose manifest declares `[[binary]]` entries, > `vibe install` MAY build them (v1: on `vibe bin sync`, see §4 — the > install itself only RECORDS the declarations; an install-time > `--build-bins` opt-in flag is v2 surface). > > > [p25] `vibe bin build […]` — release build of the named tools (default: all declared) through their exact installed package and Cargo declaration; installation is the consent and the selected work is narrated. > > > [p26] `vibe bin exec [--] ` — resolve `name` through the > CURRENT project's lockfile → its slot → the slot-resident artifact > (building the declared package target if absent), then execute with the exit > code passed through. This is the rustup dispatch model: the project's > pinned version is what runs, always. > > > [p27] **Successor to the historical first-build prompt.** Building executes package build scripts and proc-macros, so installation plus explicit target/route selection is the authorisation and the engine narrates the exact provider and target before execution. Lifecycle build does not add an allow-list, first-run prompt or `--allow-hooks` analogue; provider identity, artifact records and outcomes supply the audit trail. Existing direct `vibe bin` compatibility remains routed through its declared package rather than silently choosing ambient code. > > > [p28] Cargo needs crates.io for third-party deps unless the > local cargo cache is warm: offline boxes get the same honest failure > cargo gives, plus the hint that `cargo install --path /crates/…` > (the documented degraded path, which stays valid indefinitely) has the > same network shape — there is no offline shortcut to a first build. > > > [p29] A language-native consumer that needs a shipped > crate — a proc-macro that compiles *into* the consumer's own code (the > `specmark` case), or a binary it invokes (the `conform`/`specmap` case) — > references it **by path into the materialised slot**: > > > [p30] The consumer **excludes** `vibevm/vibedeps/` (and, for a self-hosting repo, the > in-repo `vibevm/vibepacks/` source) from its `[workspace]`, so the slot's crates > belong to the *package's* workspace, not the consumer's — Cargo forbids a > directory living in two workspaces, and this is the standard resolution for a > repo that contains a sub-project with its own workspace. > >