Манифесты зависимостей — requirements.txt, package.json, Dockerfile

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Разработчику Инженеру Тестировщику

---

Зачем отдельный файл со списком библиотек

Код проекта почти всегда опирается на сторонние пакеты — HTTP-клиент, веб-фреймворк, драйвер БД. Их исходники лежат в реестрах (PyPI, npm, NuGet, Maven Central), а в вашем репозитории хранится манифест — текстовый файл с именами и версиями.

Смысл для команды простой: открыл репозиторий → выполнил одну команду из README → получил тот же набор библиотек, что у автора. DevOps, CI и Docker используют те же файлы, что и разработчик на ноутбуке.

Два разных смысла слова «зависимости»

Здесь — пакеты из реестра (pip, npm, NuGet). Про связи между классами и модулями в архитектуре — раздел Зависимости (DIP, DI). Про сами библиотеки как понятие — Библиотека.

---

Сводка форматов по экосистемам

Экосистема	Файл манифеста	Типичная команда установки	Lock-файл (фиксация версий)
Python	requirements.txt, pyproject.toml	pip install -r requirements.txt	requirements.lock, Poetry poetry.lock
Node.js	package.json	npm ci или npm install	package-lock.json, pnpm-lock.yaml
.NET	*.csproj, Directory.Packages.props	dotnet restore	packages.lock.json
Java / Kotlin	pom.xml, build.gradle.kts	mvn dependency:resolve, ./gradlew build	Maven lock, Gradle lockfile
Rust	Cargo.toml	cargo build	Cargo.lock
PHP	composer.json	composer install	composer.lock
Go	go.mod	go mod download	go.sum
ОС в контейнере	Dockerfile (RUN apt, RUN pip…)	docker build	образ с зафиксированными слоями
Стек сервисов	docker-compose.yml	docker compose up --build	теги образов в registry

Практический разбор Python (пример с requests, venv, команды pip) — в статье Зависимости Python — requirements.txt и pyproject.toml.

---

Python — requirements.txt и pyproject.toml

requirements.txt — построчный список пакетов для pip:

requests>=2.31.0

python -m venv .venv
# Windows: .venv\Scripts\activate
# Linux/macOS: source .venv/bin/activate
pip install -r requirements.txt

pyproject.toml — единый манифест проекта (PEP 621): имя, версия, зависимости, настройки сборки. Минимальный рабочий пример с requests и одним файлом — Зависимости Python.

pip install -r requirements.txt
# или, при настроенном pyproject.toml:
pip install .

На CI и в Docker чаще всего копируют requirements.txt (или pyproject.toml) до исходников, чтобы кэшировать слой установки — см. справочник Docker и 9 практик Dockerfile.

---

JavaScript и TypeScript — package.json

{
  "name": "my-app",
  "dependencies": {
    "express": "^4.21.0"
  },
  "devDependencies": {
    "typescript": "^5.6.0"
  }
}

• npm install — подтягивает зависимости по package.json (версии могут «поплыть»).
• npm ci — строго по package-lock.json; предпочтительно на CI.

---

.NET — csproj

Зависимости объявляют в XML-проекте:

<ItemGroup>
  <PackageReference Include="Newtonsoft.Json" Version="13.0.3" />
</ItemGroup>

dotnet restore
dotnet build

---

Java — Maven и Gradle

pom.xml (Maven):

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-web</artifactId>
  <version>3.4.0</version>
</dependency>

build.gradle.kts (Gradle) — блок dependencies { implementation("…") }.

Сборка сама скачивает артефакты из Maven Central.

---

Dockerfile — зависимости внутри образа

Образ — среда «с нуля». Зависимости ОС и языка прописывают инструкциями RUN:

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "main.py"]

Тот же requirements.txt, что на машине разработчика, ставит CI при docker build. Подробнее — Docker и слои кэша. Готовые Dockerfile под Python, Node, Go и другие стеки — галерея Lab.

---

docker-compose.yml — несколько сервисов

Compose описывает набор контейнеров и их связи. Зависимости приложения по-прежнему в Dockerfile каждого сервиса; в compose указывают build, image, depends_on, порты, тома:

services:
  api:
    build: ./api
    ports:
      - "8000:8000"
    depends_on:
      - db
  db:
    image: postgres:16

depends_on задаёт порядок старта контейнеров; pip-пакеты ставятся при docker build из Dockerfile сервиса.

Готовые стеки для локальной разработки — Docker Compose — готовые стеки. Образ для build: . в compose — Dockerfile — 10 типовых образов.

CI/CD — те же файлы, чистая среда

Пайплайн на каждом прогоне поднимает пустой агент (или контейнер) и воспроизводит установку:

- run: pip install -r requirements.txt

- run: npm ci

- run: dotnet restore

Сканеры уязвимостей (Trivy, Dependabot) читают те же манифесты — безопасность CI. Минимальный MVP-пайплайн — Git и DevOps-практики. Готовые .github/workflows/ с разбором — GitHub Actions — CI/CD рецепты.

---

Что сказать коллеге или менеджеру

Ситуация	Фраза
Новый разработчик	«Клонируй репо, создай venv, выполни pip install -r requirements.txt из README»
CI падает на сборке	«Проверь, что в ветке обновлён lock / requirements и что шаг установки зависимостей есть в workflow»
Деплой в Docker	«Зависимости ставятся при docker build из Dockerfile; на сервере отдельно pip обычно не нужен»

---

Lock-файлы и воспроизводимость

Подход	Плюс	Минус
Только манифест с диапазонами (requests>=2.31)	Гибко	Разные машины могут получить разные минорные версии
Lock-файл (package-lock.json, poetry.lock)	Одинаковые версии везде	Нужно коммитить и обновлять lock при смене зависимостей
pip freeze > requirements.txt	Быстро зафиксировать текущее venv	Смешивает прямые и транзитивные пакеты; для библиотек лучше pip-tools / Poetry

---

Связанные материалы

Тема	Статья
Python, pip, пример с requests	39 — Зависимости Python
PyPI, pip в дистрибутиве	Архитектура CPython
Менеджеры пакетов в общем	Библиотека — установка пакетов
DevOps, CI	DevOps — о разделе
Docker	Контейнеризация — о разделе