А какие проблемы? Раньше ты юзал биндинг и он тебя устраивал всем. А тут он обновил свою зависимость, или ты эту же зависимость обновил у себя, и биндинг сразу же стал "тыквой"?

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

запускаешь "pylint" который отслеживает зависимости и ругается где это не надо. А где без этого никак из-за легаси, то выключаешь ругать.

Ну это можно при желании автоматизировать. Сделать плагин для cargo, который проверяет и показывает какие пакеты в твоём проекте присутствуют в двух и более версиях и почему такое случилось.

Особенно мне понравилась фишка - использовать v2 пакета, для реализации v1 этого же пакета без эмбединга. Позволяет один раз сделать прослойку для совместимости и бесплатно поддерживать актуальность v1. Для всякого энтерпрайза это же прям манна небесная.

звучит курто,  а на практике уже реализовывалось?

В Rust это один из паттернов для поддержки старой версии пакетов.

то есть это реально работает?

протсо слабо верится в "бесплатную поддержку"

А почему бы не работать - в Rust с пелёнок приучают к SemVer. И если ты ломаешь обратную совместимость, то должен обновить мажорную версию. На этом основаны дефолтные настройки менеджера пакетов. Если ты указал в зависимостях версию пакета 1.2.3, то он сам поставит самую новую версию 1.9.5, т.к. её API будет обратно совместимо. Но при этом он сам не поставит версию 2.0.0

Следовательно если ты в v1 напишешь тонкую прослойку для v2, что бы предоставить клиентам API v1, то тебе надо только протестировать хорошо эту прослойку и поддерживать только её корректность. Если она совсем "тонкая" то скорее всего это будет задача на один раз, и потом тебе не надо будет к ней возвращаться. У клиентов будет ставится твой пакет v1, и потом из его зависимостей самая новая версия из бранча v2.

Кирилл, ты описываешь достаточно узкий случай, когда у тебя пара параметров туда-сюда поменялась. Но если у тебя там редизайн и фундаментальная смена подхода, то чаще всего не получится сэмулировать старый апи

Я на практике часто сталкивался именно с этим случаем

Ну да, вполне есть такие кейсы. Но также очень часто и первый вариант кейсов случается, когда ты забыл добавить какой-то аргумент в метод, или поле в структуру, или очень важное значение в enum. А потом у тебя уже нет возможности это как-то красиво обойти без слома обратной совместимости. Приходится ломать ради "одного аргумента у метода". И тут очень хорошо получится сделать прослойку для совместимости.

Очень всё от размера команды зависит, когда это три человека понимающих друг друга с полуслова, то больше возможностей - эффективней работа.
Когда команда - 15 человек, половине из которых абсолютно срать на красоту и эффективность и проект в целом, каждая дополнительная возможность и степень свободы будут становиться врагом.
Потому что именно тот самый прекрасный коллега, который не хочет разбираться ни в чём и считает себя умнее других принесёт в зависимости 5 версий реквестс, а другой такой же коллега это заревьювит и смержит. И ебись с этим как хочешь :(

В низкоуровневых языках не получится поставить одну монолитную Django и тебе этого хватит за глаза. Там каждая более менее сложная библиотека будет подтягивать кучу зависимостей поменьше. Причём часть зависимостей вообще может не содержать реальный код, а только "кодо-генераторы" (те же макросы), или ещё какие-то Zero-Cost абстракции поверх стандартных типов данных. Поэтому dependency-hell в стиле питона тут может стать сильной головной болью буквально сразу как только ты попытаешься написать что-то с более чем одной прямой зависимостью.

вероятно я просто не понимаю этой боли (и хорошо что не понимаю) но решая проблему так как ты описал, сколько других проблем заносится? и какой широты возможности предоставляются людям которые копипастят с SO?
в общем одно решили, другое сломали, всё как всегда

Можно к этому относится как к парадигме микросервисов. Вот ты лично пилишь один мелкий сервис и отвечаешь за него. А кто-то ещё пилит другие сервисы-библиотеки, к которым у тебя есть доступ только через публичный API. Что там у них внутри - это не твоя проблема, пока это не мешает твоему коду. Как-только станет мешать - тогда и будешь с этим разбираться.

у меня боль совершенно персональная, было как минимум две области на проекте, куда комитили пара человек, и делали это согласованно и в общем направлении, и было понятно что и как работает.
потом манагеры решили, что каждый на проекте должен уметь делать всё, и комитить (и ревьювить друг друга) начали все подряд.
за год те части проекта буквально пришли в упадок.
и теперь те же манагеры нанимают специального человека наводить порядок.
но у него ничего не получится, потому что все подряд комитить продолжат.
это не связано ни с растом ни с позможностью запиливать кучу версий одной библиотеки.
это связано с тем, что прежде чем давать кому-то мощные и сложные инструменты, надо бы позаботиться о проверке уровня культуры разработки.
как его проверять - отдельный сложный вопрос

что-то я похоже сказал какие-то слишком очевидные вещи :)

а что, не было какого-то feature owner'а с главным аппрувом?

ХЗ, лично мне не нравится когда есть части кода, которые знает "только вот тот чувак", потому что бас-фактор никто не отменял
Логично бы было чтобы коммитили туда все, а ревьюил тот который знает как должно быть хорошо