А дело не в компиляторе. Дело в лютой когнитивной сложности такого подхода. Вместо того, чтобы помнить про реквестс, мне надо теперь помнить про 2 версии, чем они отличаются, почему тут нужно именно 2, и что будет, если я вдруг их перепутаю и тп

Какая тебе разница как библиотека vkontakte шлёт HTTP запросы? Сегодня она юзает requests, а завтра перейдёт на aiohttp. Это не твоя забота - ты доверился этой либе и используешь её API как есть, как чёрный ящик.

Ты ведь не интересушься какие зависимости использовались для сборки libjpeg в твоей системе? И тут так же.

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

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

Идёшь в гитхаб к автору либы, и просишь бекпортировать фикс в старую мажорную версию его либы, что бы либа vkontakte "починилась". Ну или идёшь к автору vkontakte и просишь его перейти на новую версию requests.
А ещё лучше - сразу заслать им пул-реквест.

И зачем в таких подходах разрешать иметь 2 версии в проекте? Вопрос и к Антону, и к Кириллу.

Потому что это решает проблему с зависимостями. Потому что тебе на самом деле плевать на эту проблему. Ты хочешь что бы твой код использовал новый requests и хочешь что бы libffmpeg просто распаковывал видосики. Каким образом libffmpeg скачивает эти видосики по http - это лишняя головная боль. Если ты хочешь это контролировать - форкаешь libffmpeg и делаешь как тебе это надо.

Когда ты встал на путь использования чужого кода, то у тебя остаётся мало вариантов для маневра

вообще удивительно, но даже в весьма консервативном го можно так делать

// go.mod
module multiversion

go 1.13

replace github.com/pkg/errors/081 => github.com/pkg/errors v0.8.1
replace github.com/pkg/errors/091 => github.com/pkg/errors v0.9.1

// main.go
package main

import (
    "fmt"
    errors081 "github.com/pkg/errors/081"
    errors091 "github.com/pkg/errors/091"
)

Поди читали недавнюю новость - ментейнеры дистрибутивов (по крайней мере Debian) наконец то догадались, что было плохой идеей класть в репу каждый npm пакет по отдельности и прописывать его в зависимости к другим deb пакетам. Потому что этих npm миллионы и почти все они - это библиотеки. Это привело к невозможности мониторить и вовремя обновлять эти npm, т.к. уже вполне конкретные приложения для node.js зависели от разных версий одного и того же npm.
Теперь они разрешили ментейнерам приложений эмбедить npm-ки в свой deb.

эм... зачем в репозитории операционки npm либы?

Хрен знает, я этого тоже не очень понимал в контексте питона.

Да видел я в гробу эти форки. Так и Эрланге много где принято. Не надо себе врать. Форк - это раз внесли пару изменений и все, библиотека теперь в бронзе отлита, ее в жизни теперь никто обновлять не будет.

Это не решает проблему с зависимостями, это иллюзия какая-то. Это именно “построить вокруг панельки и торговый центр”. Сделать вид, что иначе нельзя. Можно. Если библиотека вовремя не обновляется по каким-то причинам, и ты сам починить это не можешь, то вам с ней просто не по пути. Если альтернатив нет, тогда да, это твой боттлнек, что поделать. Однако если у тебя какая-то часть проекта не обновляется, то это автоматически легаси, с которым постоянно приходится ковыряться и копаться.

Я ж в энтерпрайзе сейчас. У нас Python 2.7, и будет 2.7 до тех пор, пока поставщики биндингов к одной ключевой системе не снизойдут до Python 3. Сами мы их сделать по лицензионным причинам не можем.

// go.mod
module multiversion

go 1.13

replace github.com/pkg/errors/081 => github.com/pkg/errors v0.8.1
replace github.com/pkg/errors/091 => github.com/pkg/errors v0.9.1

// main.go
package main

import (
    "fmt"
    errors081 "github.com/pkg/errors/081"
    errors091 "github.com/pkg/errors/091"
)

Штука в том, что так можно делать только в твоих модулях. В чужих - нет. Есть большая разница

Ну вот ведь - сам страдаешь от того что не можете использовать Python 3, т.к. биндинги его не поддерживают. То же самое и с версиями пакетов - в питоне приходится либо не юзать "биндинг" который юзает старые зависимости. Либо самому "опускаться" до его уровня и юзать старьё, даже если это какой-то малозначимый для биндинга вариант left_pad.
В Rust у тебя есть 3-ий вариант - самому юзать всё новое, а биндинг пускай юзает старьё. И то что он его юзает - это вполне видно по файлу cargo.lock в котором есть версии всех зависимостей. Т.е. это как бы не секрет, про который ты узнаешь только после взлома твоей системы в продакшене.

и много человек будут смотреть в эти локфайлы, понимать, где кто и почему?

Ну если ему важно - то посмотрит. Кроме того видно ведь какие пакеты ставятся в момент сборки. Вполне можно глазом зацепиться за две разных версии одного пакета.

Но зато насколько облегчает поддержку проекта и обновление зависимостей. У тебя ничего не ломается только от того что биндинг вдруг перешёл на новую, не совместимую с твоей версию requests.

Пускай лучше сломается, чем я тихо, без объявления войны, получу вот такие проблемы с разошедшимися версиями

Но к сожалению такое возможно видимо только в языках со статической типизацией. Иначе ты о не совместимых версиях структур одной либы узнаешь только в рантайме (если повезёт)