поэтому теоретизирую

я не дружу с головой, поэтому мой пакетный менеджер не будет полагаться на дружбу с головой и словесные традиции не ломать совместимость в новой версии библиотеки

крч заебало

покажешь пример, поговорим

а так это сферический конь в вакууме

cargo и npm решают это возможностью даунгрейда при поломке из-за обновления

Примеров не покажу =) Мне даже своим проектам придумывать трёхчисленные версии лень, не то что выискивать какие-то исторические ситуации

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

Но вот по текущему прототипу, добавляя новую зависимость в проект, ты пользуешься перманентной прямой ссылкой на zip нужной тебе версии библиотеки, а хешами заведует уже пакетный менеджер

Библиотека A использует библиотеку B версии 1.2.3
А ты используешь A и B версии 1.2.4
Будет ли несоответствие типов из-за этого?

несоответствия не будет

lib-store/A-slfkgjdflkgjdflg(хеш от A 1.2.4)
lib-store/B-akodfjsoifgjos(хеш от B 1.2.4)
lib-store/B-sdfgospfhgfgg(хеш от B 1.2.3, которой пользуется А 1.2.4)

Путь к нужной библиотеке, включающий хеш B 1.2.3, содержится в исходниках А 1.2.4
Путь в исходниках к используемой мной B 1.2.4 в моем проекте тоже содержит хеш этой 1.2.4.

То есть если даже мне захочется использовать в одной моей либе две разных B, я просто пропишу соответствующие пути. А пакетный менеджер отвечает только за доставку

lib-store/A-slfkgjdflkgjdflg(хеш от A 1.2.4)
lib-store/B-akodfjsoifgjos(хеш от B 1.2.4)
lib-store/B-sdfgospfhgfgg(хеш от B 1.2.3, которой пользуется А 1.2.4)

А как дальше потом использовать 2 разные версии?

Как захочется.

Кстати, а nix ты смотрел?

в питоне это было бы какое-нибудь

import "A-sfgfdgdfgfdg" as A123
import "A-hdgiohjdglgh" as A124

например. То есть средствами языка и\или системы сборки

А пакетный менеджер отвечает только за доставку и сверку хешей, чем облегчает мне задачу его разработки ;)

import "A-sfgfdgdfgfdg" as A123
import "A-hdgiohjdglgh" as A124

Не, смотри. Ты притащил либу А, которая зависит от версии 1.2.4 а остальной проект от 1.2.3
В либе A то не будет этого импорта через хеш.

red75prime diabolo @GabrielFallen и все остальные из мейн-чата, кто участвова.

Спасибо за дискуссию про lexicographic orders, вы были правы, а я – нет :) Сори, если кому-то показалось, что я плохо о них думаю, это не так.

Вот тут написано почему https://en.wikipedia.org/wiki/Total_order#Orders_on_the_Cartesian_product_of_totally_ordered_sets

либа А использует 1.2.3. Ей нельзя насильственно скормить 1.2.4, только форкнуть и использовать AFork, использующий B 1.2.4

Или придумать что-то еще, вроде инверсии зависимостей, чтобы А ни от чего не зависела, а ты в своём проекте импортировал B 1.2.4 и необходимые функции оттуда скармливал бы в качестве аргументов для функций из А. Но по умолчанию да, такое насильственное скармливание новых версий тем, кто хочет старые - не поощряется, и пакетный менеджер (конкретно мой) подменами не занимается