Hacker News Digest

Инструмент modshim позволяет переопределять и настраивать Python-пакеты без изменения их исходного кода. Это решение даёт возможность вносить изменения в зависимости, исправлять ошибки или добавлять функциональность без создания форка проекта. Подобные инструменты часто используют техники перехвата импорта или патчирования модулей во время выполнения.

Проект может быть особенно полезен для разработчиков, которым нужно быстро внести небольшие изменения в сторонние библиотеки, но у них нет возможности или желания изменять исходный код. Это упрощает управление зависимостями и ускоряет разработку, позволяя избежать сложного процесса создания и поддержки форков.

• Пользователи обсуждают инструмент для monkey-patching в Python, который использует временный импорт-хук для обхода импортов и позволяет документировать код в стиле literate-code.
• Некоторые участники отмечают, что такой подход может быть неудобен при работе с внешними зависимостями, особенно если они часто обновляются, и что это может привести к необходимости поддерживать форк.
• Участники также обсуждают, что вместо использования такого инструмента, можно было бы просто форкнуть библиотеку и внести изменения, что может быть более устойчивым решением в долгосрочной перспективе.
• Также поднимается вопрос о том, что если библиотека, которую вы хотите изменить, имеет сложную систему импортов и экспортов, то такой инструмент может не справиться с этим.
• В конце обсуждение сместилось в сторону обсуждения того, что если вы контролируете все импорты, то вы можете просто сделать сабкласс или обвернуть нужные части библиотеки, что может быть более питоничным способом решения проблемы.

Wagtail CMS обновил свой веб-сайт, добавив новую страницу «О нас», где описаны основные преимущества и возможности CMS. Вместо традиционных пунктов меню теперь используются интерактивные карточки с иконками, что улучшает пользовательский опыт. На сайте также представлена информация о команде Wagtail, его функциях, доступности и устойчивости, что делает его более прозрачным и доступным для новых пользователей. Обновление подчеркивает важность открытости и удобства, что может привлечь больше разработчиков и контент-менеджеров.

• uv стал фактическим стандартом для управления зависимостями и окружениями, потому что он быстрый и простой в использовании, но это вызвало споры о том, действительно ли он лучше, чем pip и другие инструменты, особенно в контейнерах и CI/CD.
• Некоторые разработчики утверждают, что uv не подходит для контейнеров, потому что он не может использовать системный Python, и это вызывает споры о том, действительно ли это проблема.
• Пользователи, которые привыкли к pip и другим инструментам, иногда утверждают, что uv не предоставляет никаких преимуществ, и что это просто "Rust фанатство", но другие считают, что скорость и простота использования делают его лучшим выбором.
• Некоторые разработчики считают, что uv не подходит для использования в контейнерах, потому что он не может использовать системный Python, и это вызывает споры о том, действительно ли это проблема.
• Некоторые разработчики считают, что uv не подходит для использования в контейнерах, потому что он не может использовать системный Python, и это вызывает споры о том, действительно ли это проблема.

Представлен fossabot — ИИ-агент для стратегического обновления зависимостей, который работает как инженер: исследует версии, оценивает влияние на приложение и адаптирует код при необходимости. В отличие от инструментов вроде Dependabot, которые делают минимальные обновления для исправления уязвимостей, fossabot способен на сложные мажорные обновления, требующие анализа рисков и преимуществ.

Доступен в публичном превью для JavaScript и TypeScript экосистем. Агент анализирует код на предмет совместимости, выявляет устаревшие методы и даже предлагает модернизацию синтаксиса. Пользователи получают $15 ежемесячного кредита. Ключевое преимущество — сокращение рутины и предотвращение застоя обновлений в бэклоге за счёт автоматизации стратегических решений.

• Обсуждение возможностей ИИ для анализа безопасности и обновления зависимостей в кодовых базах, особенно в динамически типизированных языках.
• Отмечается сложность оценки миграций зависимостей из-за уникальности контекста каждой кодовой базы.
• Подчеркивается, что задача масштабирования глубокого статического анализа кода сложна и ресурсозатратна.
• Упоминается, что GitHub уже исследовал подобные подходы, но столкнулся с трудностями в достижении удовлетворительных результатов.
• Участники видят в этом перспективную нишу для ИИ-агентов из-за шаблонности задач и отсутствия строгих временных ограничений.

Devbox — это инструмент для создания изолированных сред разработки на основе Docker. Каждый проект работает в собственном контейнере, что предотвращает конфликты зависимостей и сохраняет чистоту основной системы. Контейнеры автоматически перезапускаются и сохраняются между перезагрузками, а код остаётся на файловой системе хоста для удобного редактирования.

Инструмент предлагает простые команды CLI, встроенные проверки безопасности и шаблоны для Python, Node.js, Go и веб-разработки. Также поддерживаются расширенные функции Docker, такие как проброс портов, монтирование томов и настройка переменных окружения.

• Обсуждаются сходства и отличия Devbox от альтернатив: Devcontainers (от Microsoft), Toolbx, Distrobox и других, с акцентом на поддержку в разных IDE и сложность их реализации вне VSCode.
• Поднимается проблема конфликта имен с другими проектами, в первую очередь с Devbox от Jetify, что указывает на возможное отсутствие анализа существующих решений.
• Отмечаются вопросы о безопасности и изоляции, в частности, возможность использования Docker-in-Docker и её последствия.
• Участники делятся личным опытом использования Devbox и аналогичных инструментов, отмечая их удобство для создания воспроизводимых сред без потери производительности.
• Обсуждается, решает ли подход с контейнерами проблему "dependency hell" и насколько он оправдан для разных языков и типов разработки (веб, мобильная).

Автор успешно удалил около 120 неиспользуемых зависимостей в Nx-монополии, сократив время установки на минуту и уменьшив количество уязвимостей. Для этого он использовал инструмент Knip вместо устаревшего depcheck, так как он лучше работает с современными монополями и анализирует импорты и конфиги. Knip выдал список потенциально ненужных пакетов, но около 40% из них оказались ложными срабатываниями — например, зависимости использовались в скриптах, конфигах Jest или CSS.

Процесс включал удаление кандидатов, последующую проверку сборки, тестов и запуска приложений, а затем восстановление пакетов, которые оказались нужны, с добавлением их в ignore-лист Knip. Автор настроил конфиг под монополию, игнорируя специфичные для проектов ложные срабатывания. Изменения были мержены одной партией в тихое время с предварительным деплоем в preview-ветку для проверки. В будущем планируется интегрировать Knip в CI для предотвращения накопления мусора.

• Обсуждаются причины накопления неиспользуемых зависимостей: невнимательность разработчиков, множественные рефакторинги, устаревшие библиотеки в монорепозиториях и автоматическое добавление пакетов без контроля.
• Участники отмечают, что инструменты вроде Knip помогают выявлять мертвые зависимости и файлы, но не оценивают качество кода, и окончательное решение остается за человеком.
• Экосистема и практики разработки (например, pip freeze или npm install без проверки) поощряют накопление лишних пакетов.
• В больших и старых проектах, особенно с микросервисами и смешанными стеками, "хлам" накапливается быстро из-за миграций и отсутствия регулярной очистки.
• Некоторые видят в постоянной борьбе с кликбейтом и переименованиях заголовков раздражающий и непродуктивный аспект обсуждений.

• Обсуждаются строгие правила CRAN для R-пакетов, требующие обратной совместимости и тестирования всех зависимых пакетов при обновлении, что сравнивают с монорепозиторием.
• Поднимаются проблемы других экосистем (Python, npm), где распространены ломающие изменения и конфликты зависимостей, и отмечается стабильность R.
• Участники спорят о практичности подхода CRAN: одни видят в нём бремя для разработчиков, другие — выгоду для научной воспроизводимости и пользователей.
• Предлагаются альтернативы и обходные пути, такие как полное форкирование, версионирование API или контейнеризация.
• Отмечается уникальная философия R-сообщества, ориентированная на статистиков, а не на разработчиков, что объясняет такие жёсткие требования.

Пакетные менеджеры — зло

Пакетные менеджеры автоматизируют ад зависимостей: скачивают пакет → его зависимости → зависимости зависимостей… и ты в аду. Вручную хотя бы думаешь: «а надо ли?»

Большинство языков не знают, что такое «пакет», поэтому менеджер сам его придумывает. В итоге появляются «менеджеры менеджеров» (npm, yarn, pnpm…).

Языки с толстой стандартной библиотекой (Go, Odin) откладывают ад: 90 % задач решаются без сторонних пакетов.

Каждая зависимость — это долг: баги, security, поддержка. Мы взяли SDL2 — и год убили на чужие баги; проще написать своё, чем обновиться до SDL3.

Доверие к случайному коду из интернета — социальная болезнь программистов.

• Критика менеджеров пакетов сводится к тому, что они «автоматизируют ад зависимостей», скрывая от разработчика реальные издержки и риски.
• Автор предлагает вручную копировать и фиксировать нужные версии библиотек, чтобы осознанно контролировать, что именно попадает в проект.
• Оппоненты считают идею регрессом: ручное управление не масштабируется, тормозит разработку и не решает проблему транзитивных зависимостей.
• Поддержка Cargo, npm и прочих инструментов признаётся необходимой, но критикуется культура «микро-зависимостей» и отсутствие вендоринга.
• Компромисс видят в строгом вендоринге (Google), фиксации версий, feature-gates и использовании «batteries-included» стандартных библиотек (Go).

Представьте, вы пишете проект и вам нужна библиотека — назовем ее libpupa.

Вы находите текущую версию 1.2.3 и добавляете в зависимости: "libpupa": "1.2.3" Автор libpupa 1.2.3 в свою очередь зависел от liblupa версии 0.7.8 и записал это: "liblupa": "0.7.8" То есть libpupa 1.2.3 навсегда зависит от liblupa 0.7.8. Алгоритм разрешения зависимостей простой и детерминированный: берем версии верхнего уровня, затем версии их зависимостей, и так далее. Достаточно указать только верхние уровни — транзитивные получатся одинаковыми всегда. Зачем отдельный lockfile?

Но люди изобрели lockfile из‑за диапазонов версий. Диапазоны делают сборку зависимой от времени: сегодня вы получите liblupa 0.7.8, через 10 минут — 0.7.9. Это определяется не при публикации, а при сборке: вы можете подтянуть версию, которой не существовало на момент выпуска libpupa 1.2.3. Откуда автор libpupa знает, что будущая 0.7.9 не сломает его код? Семантическое версионирование — это лишь намек, не гарантия.

И смешно то, что эти диапазоны все равно «замораживают» в lockfile, и вы не получаете предполагаемой пользы. «Перегенерируй lockfile и обновись» — это ничем не отличается от обновления верхнеуровневых зависимостей. «Lockfile решает конфликты версий?» — нет: библиотека либо работает с новой версией, либо нет; запись «0.7.*» не помогает — все равно нужно выбрать рабочую версию.

«Но раз lockfile существует, значит, нужен!» — не обязательно. Пример: Maven. Экосистема Java 20 лет обходится без lockfile, при этом тянет сотни библиотек — и все детерминировано.

Вывод: lockfile усложняет без достаточных причин. Менеджеры зависимостей могут работать без него.

UPD: В Maven при конфликте транзитивных зависимостей выбирается версия, ближайшая к корню. Это детерминированно и позволяет переопределять версии. Если вышла d 2.1 с патчами безопасности, добавьте ее в корень — она и будет выбрана, не дожидаясь обновлений у всех. Если автоматически брать самую большую версию, вы потеряете возможность переопределения.

• Обсуждение крутится вокруг необходимости lock-файлов и версионирования: одни считают, что фиксированные версии и детерминированные алгоритмы достаточно, другие настаивают, что lock-файлы критичны для воспроизводимости и безопасности.
• Приводят примеры из экосистем Maven/Java, Go (MVS), Cargo/Rust, .NET, Scala: у каждого свои компромиссы; даже при детерминированном резолве сеть/репозитории делают сборки недетерминированными без lock-файлов и хэшей.
• Аргументы за версии-диапазоны: автоматическое получение патчей безопасности без вмешательства авторов верхнеуровневых библиотек; но это ломается при конфликтующих транзитивных зависимостях и несовместимых API/ABI.
• Много комментариев о том, что lock-файлы особенно нужны приложениям (прод, стейджинг, аудит), а для библиотек — меньше, но всё равно полезны из-за пересборок и целостности (хэши артефактов).
• Подчёркивают проблемы разных языков: в компилируемых — типы из разных версий несовместимы; в JS Node могут сосуществовать несколько версий, но это не решает безопасность/детерминизм.
• Некоторые отмечают, что главная путаница — не в lock-файлах, а в культуре семвера, централизованных репозиториях и UX инструментов; предлагают BOM/snapshot-подходы и периодические обновления с тестами/реновейтом.
• Отдельная ветка критикует дизайн сайта с анимированными иконками, мешающими чтению.