Comments 9
крутая тема с запретом на открытую зависимость
В этом плане крейт cargo-edit очень удобен: не нужно лезть на crates.io проверять какая последняя вресия крейта, который хочешь добавить в зависимости.
В cabal (это такой cargo для haskell) с зависимостями от конкретных версий твориться ужас. Собрать что-то с зависимостями от двух пакетов редко просто так удается, посколько они зависят от конкретной версии третьего.
Это не проблема конкретных версий, это проблема того как происходит работа с зависимостями. В том же npm(который в моей вселенной —образец пакетных менеджеров для языка) разные пакеты могут зависеть от разных версий и ничего страшного не произойдет так как каждый пакет будет видеть только свою версию.
В компилируемых языках с этим всегда сложнее, но это, разумеется, не повод указывать * вместо версии. Версии всегда должны указываться максимально конкретно, иначе есть риск попасть в другой ад: вчера собиралось а сегодня, после обновления модулей, перестало.
В компилируемых языках с этим всегда сложнее, но это, разумеется, не повод указывать * вместо версии. Версии всегда должны указываться максимально конкретно, иначе есть риск попасть в другой ад: вчера собиралось а сегодня, после обновления модулей, перестало.
Две версии библиотеки водной программе — лишний расход ресурсов. Особенно это неприятно в языке, претендующим на максимальную эффективность и использование во встраиваемых системах.
Лично я считаю, что разработчики библиотеки обязаны заботится об обратной совместимости и правильно ориентироваться на самую свежую стабильную версию. Конечно, жизнь не идеальна, но стремиться к этому надо.
Лично я считаю, что разработчики библиотеки обязаны заботится об обратной совместимости и правильно ориентироваться на самую свежую стабильную версию. Конечно, жизнь не идеальна, но стремиться к этому надо.
Ну встраиваемые системы это совсем другое, к тому же раст, насколько я знаю, пока не очень с ними дружит, нужно попыхтеть чтобы собрать вся для АРМа, например. А во всех остальных случаях, я предпочту чуть больший расход ресурсов, чем ад совместимости. Вы ведь хаскеллер? Тогда чего я вам объясняю? :) Слава богу, песочницы появились — и на том спасибо.
Насчет обратной совместимости, вы это серьезно? Даже в собственном проекте это не всегда возможно, и почти всегда нужно прилагать непропорционально растущие с размером проекта усилия. А сторонние разработчики, разумеется, никому ничего не должны и не будут.
В конце концов, если будет нужно, всегда можно форкнуть проблемные модули и адаптировать их для использования с какой то конкретной версией третьего модуля. Но я совершенно точно не хочу делать это всегда. По умолчанию, пусть все просто работает и каждый собирается с теми версиями третьих модулей, с которыми ему хочется.
Насчет обратной совместимости, вы это серьезно? Даже в собственном проекте это не всегда возможно, и почти всегда нужно прилагать непропорционально растущие с размером проекта усилия. А сторонние разработчики, разумеется, никому ничего не должны и не будут.
В конце концов, если будет нужно, всегда можно форкнуть проблемные модули и адаптировать их для использования с какой то конкретной версией третьего модуля. Но я совершенно точно не хочу делать это всегда. По умолчанию, пусть все просто работает и каждый собирается с теми версиями третьих модулей, с которыми ему хочется.
Ну для встроенных систем и на С собраться нетривиально. Просто в интернетах больше информацииб как проблемы решать.
Хотя в cabal часто указывают точные версии, я несколько раз скачивал исходники библиотек, правил им зависимосим на более свежие и все прекрасно работало. Уж на языках со статической типизацией заботится об совместимости.
Был бы язык и менеджер пакетов, где интерфейс библиотеки отделен от реализации и в зависимостях указывался интерфейс, а при сборке выбиралась бы предпочитаемая реализация…
Хотя в cabal часто указывают точные версии, я несколько раз скачивал исходники библиотек, правил им зависимосим на более свежие и все прекрасно работало. Уж на языках со статической типизацией заботится об совместимости.
Был бы язык и менеджер пакетов, где интерфейс библиотеки отделен от реализации и в зависимостях указывался интерфейс, а при сборке выбиралась бы предпочитаемая реализация…
Rust не допустит ситуации, когда в одном проекте у вас одновременно одна и та же библиотека разных версий просто потому, что необходимо гарантировать, что структуры, порожденные этой библиотекой, будут совместимы с этой же библиотекой. Представте себе ситуацию, что библиотеки A и B зависят от библиотеки C разных и не совместимых версий. Если вы подключите одновременно библиотеки A и B, а затем получите данные из библиотеки A (которая в свою очередь получит их из С), которые вы передадите в библиотеку B (которая в свою очередь делегирует задачу С), то у вас вылезет просто несовместимость библиотеки с самой собой на уровне ABI.
Чтобы избежать подобного ада, в экосистеме Rust активно насаждается semver. Если вы пишете, что ваша библиотека зависит от библиотеки C версии 1.2, то на самом деле это означает, что вам подойдет любая версия C, совместимая с 1.2, вполть до версии 2.0 не включительно.
Чтобы избежать подобного ада, в экосистеме Rust активно насаждается semver. Если вы пишете, что ваша библиотека зависит от библиотеки C версии 1.2, то на самом деле это означает, что вам подойдет любая версия C, совместимая с 1.2, вполть до версии 2.0 не включительно.
Sign up to leave a comment.
Анонс Rust 1.6