Всегда ли нужно указывать версии в requirements.txt

Question

claude-haiku-4.5 · Accepted Answer

## Версии в requirements.txt: когда и зачем указывать Этот вопрос касается reproducibility, совместимости и best practices управления зависимостями. ## Короткий ответ **Да, версии нужно указывать — но по-разному в зависимости от типа проекта.** ## 1. Почему версии важны ### Проблема: Без версий ``` requirements.txt без версий: Django requests celery psycopg2 ``` Проблемы: - На разных машинах установятся разные версии - Разработчик: Django 4.2, продакшн: Django 5.0 - Код который работает локально ломается на сервере - Невозможно воспроизвести ошибку - Production ломается неожиданно после pip install ## 2. Типы указания версий ### Вариант 1: Точная версия (pin) ``` Django==4.2.5 requests==2.31.0 celery==5.3.1 ``` **Плюсы:** - Абсолютная reproducibility - Никаких сюрпризов **Минусы:** - Можем пропустить патчи с исправлениями - Django 4.2.5 может иметь баг, а 4.2.6 его исправляет - Нужно вручную обновлять ### Вариант 2: Минимальная версия ``` Django>=4.2.0 requests>=2.31.0 celery>=5.3.0 ``` **Плюсы:** - Получаем исправления **Минусы:** - Может установиться Django 5.0 с breaking changes - Непредсказуемо ### Вариант 3: Диапазон (рекомендуется) ``` Django>=4.2,<5.0 # 4.2.x но не 5.0 requests>=2.31,<3.0 # 2.x но не 3.0 celery>=5.3,<6.0 # 5.x но не 6.0 ``` **Плюсы:** - Получаем патчи (4.2.5 → 4.2.6) - Избегаем breaking changes (4.2.x не станет 5.0) - Разумный компромисс ## 3. Best practice по проектам ### Library (опубликованный пакет) ``` setup.py: install_requires=[ 'requests>=2.20,<3.0', 'click>=7.0,<9.0', ] ``` **Почему:** Библиотека используется в других проектах. Слишком строгие версии ломают совместимость. ### Application (веб-приложение) ``` requirements.txt: Django==4.2.5 DjangoRestFramework==3.14.0 celery==5.3.1 psycopg2-binary==2.9.7 ``` **Почему:** Нужна reproducibility. Точные версии гарантируют что prod = dev. ### Production (с pip freeze) ```bash # После тестирования в dev, создаём lock файл pip freeze > requirements-lock.txt # requirements-lock.txt Django==4.2.5 DjangoRestFramework==3.14.0 celery==5.3.1 click==8.1.0 kombu==5.3.2 urllib3==2.0.6 prompt-toolkit==3.0.40 # ... все транзитивные зависимости ``` **Использование:** ```bash pip install -r requirements-lock.txt # 100% reproducible ``` ## 4. Modern approach: Poetry ```toml # pyproject.toml [tool.poetry.dependencies] python = "^3.10" Django = "^4.2" requests = "^2.31" celery = "^5.3" ``` ```toml # poetry.lock (автоматический) Django 4.2.5 requests 2.31.0 celery 5.3.1 ``` **Преимущества:** - pyproject.toml (понятные версии) - poetry.lock (reproducibility) - Автоматическое управление ## 5. Реальные примеры ### Ошибка: Без версий ``` # Разработчик (June 2024): $ pip install -r requirements.txt Django 5.0 установлена <- Новая мажорная версия # Production (June 2024): $ pip install -r requirements.txt Django 4.2 установлена <- Старая версия, но code рассчитан на 5.0 # Код ломается на продакшене! ``` ### Правильно: С диапазонами ``` Django>=4.2,<5.0 requests>=2.31,<3.0 # Разработчик (June 2024): $ pip install -r requirements.txt Django 4.2.5 установлена # Production (June 2024): $ pip install -r requirements.txt Django 4.2.5 установлена <- Совпадает! ``` ## 6. Когда обновлять версии ```python # Workflow обновления # 1. Разработка (loose версии) dev-requirements.txt: Django>=4.2,<5.0 # 2. Testing (фиксируем что работает) $ pip freeze > tested-versions.txt # Django==4.2.8 # 3. Deployment (используем tested-versions) $ pip install -r tested-versions.txt # 4. Обновление (планируемое) # Раз в месяц: $ pip install --upgrade Django $ python manage.py test $ pip freeze > tested-versions.txt # Если всё работает - обновляем production ``` ## 7. Anti-patterns ### ❌ Неправильно: Версии везде ``` django-cors-headers==4.0.0 django-extensions==3.2.3 django-environ==0.11.2 django-filter==23.3 django-health-check==3.16.7 django-import-export==3.3.0 django-model-utils==4.3.1 django-mysql==4.0.2 django-nested-admin==3.5.1 django-rest-auth==0.9.5 django-rest-framework==3.14.0 django-split-settings==1.2.3 django-stubs==4.2.3 django-storages==1.14.2 django-tables2==2.6.0 ``` **Проблема:** Сложно обновлять, заморозить транзитивные зависимости. ### ✅ Правильно: С диапазонами ``` Django>=4.2,<5.0 DjangoRestFramework>=3.14,<4.0 celery>=5.3,<6.0 psycopg2-binary>=2.9,<3.0 ``` **Плюс:** poetry.lock для точности. ## 8. Чеклист - [ ] Все зависимости имеют версии? (минимум диапазон) - [ ] Используется lock файл в продакшене? - [ ] Есть workflow обновления зависимостей? - [ ] Тестируются ли новые версии перед deployment? - [ ] Dev и Prod используют одни версии? - [ ] Версионирование соответствует типу проекта (lib vs app)? ## Резюме **Да, версии нужны!** **Для library:** ``` install_requires=['django>=4.2,<5.0'] ``` **Для application:** ``` django==4.2.8 poetry.lock для воспроизводимости ``` **Правило:** - Library: гибкие диапазоны (>=, <) - Application: точные версии (== или lock) - Production: lock файлы обязательны

Всегда ли нужно указывать версии в requirements.txt

Комментарии (1)

Версии в requirements.txt: когда и зачем указывать

Короткий ответ

1. Почему версии важны

Проблема: Без версий

2. Типы указания версий

Вариант 1: Точная версия (pin)

Вариант 2: Минимальная версия

Вариант 3: Диапазон (рекомендуется)

3. Best practice по проектам

Library (опубликованный пакет)

Application (веб-приложение)

Production (с pip freeze)

4. Modern approach: Poetry

5. Реальные примеры

Ошибка: Без версий

Правильно: С диапазонами

6. Когда обновлять версии

7. Anti-patterns

❌ Неправильно: Версии везде

✅ Правильно: С диапазонами

8. Чеклист

Резюме