RP
ты не прав
Size: a a a
2020 May 24
EG
ты не прав
Спасибо за аргументированный ответ.
RP
потому что у тебя неаргументированный наезд
EG
Я уже три раза повторил.
1. При любом изменении в Cargo.toml (например, добавлении новой зависимости) может изменится версия всех пакетов
2. Все пакеты с изменившейся версией нужно просмотреть ещё раз
3. crates.io даже не гарантирует, что код на гитхабе имеет хоть что-то общее с кодом в crates.io, что ещё сильнее усложняет задачу.
1. При любом изменении в Cargo.toml (например, добавлении новой зависимости) может изменится версия всех пакетов
2. Все пакеты с изменившейся версией нужно просмотреть ещё раз
3. crates.io даже не гарантирует, что код на гитхабе имеет хоть что-то общее с кодом в crates.io, что ещё сильнее усложняет задачу.
RP
хочешь аргументированного ответа - пили MRE, я тебе покажу, какие маны по карго надо читать, чтобы не столкнуться с этой проблемой
RP
Я уже три раза повторил.
1. При любом изменении в Cargo.toml (например, добавлении новой зависимости) может изменится версия всех пакетов
2. Все пакеты с изменившейся версией нужно просмотреть ещё раз
3. crates.io даже не гарантирует, что код на гитхабе имеет хоть что-то общее с кодом в crates.io, что ещё сильнее усложняет задачу.
1. При любом изменении в Cargo.toml (например, добавлении новой зависимости) может изменится версия всех пакетов
2. Все пакеты с изменившейся версией нужно просмотреть ещё раз
3. crates.io даже не гарантирует, что код на гитхабе имеет хоть что-то общее с кодом в crates.io, что ещё сильнее усложняет задачу.
1) это не так
2) нужно, но ты не обновляй
3) смотри в формат крейтофайлов
2) нужно, но ты не обновляй
3) смотри в формат крейтофайлов
EG
1) это не так
2) нужно, но ты не обновляй
3) смотри в формат крейтофайлов
2) нужно, но ты не обновляй
3) смотри в формат крейтофайлов
Это так. Все зависимости, которые указаны с версией
"x.y.z", cargo имеет право обновить до любой версии "x.y.a", что написано в любимых тобой мануалах по карго.RP
в моих любимых мануалах даже описано, как делать, чтобы оно не обновляло
RP
просто иди и читай
EG
в моих любимых мануалах даже описано, как делать, чтобы оно не обновляло
Оно не будет обновлять прямые зависимости, но с косвенными всё ещё проблема.
RP
и косвенные не будет)
RP
которые транзитивные
G
Я уже три раза повторил.
1. При любом изменении в Cargo.toml (например, добавлении новой зависимости) может изменится версия всех пакетов
2. Все пакеты с изменившейся версией нужно просмотреть ещё раз
3. crates.io даже не гарантирует, что код на гитхабе имеет хоть что-то общее с кодом в crates.io, что ещё сильнее усложняет задачу.
1. При любом изменении в Cargo.toml (например, добавлении новой зависимости) может изменится версия всех пакетов
2. Все пакеты с изменившейся версией нужно просмотреть ещё раз
3. crates.io даже не гарантирует, что код на гитхабе имеет хоть что-то общее с кодом в crates.io, что ещё сильнее усложняет задачу.
1-2: писать прямо в проекте тесты на используемые библиотеки. Так при обновлении библиотек можно быть уверенным в их правильности + помогает другим людям и тебе в том числе понять как использовать библиотеки
RP
не, ты не прав. в теории в новые версии build.rs тебе может майнинг засунуть в бинарь
RP
@emmanuelGoldstein короче твои наезды понятны, но не верны.
EG
не, ты не прав. в теории в новые версии build.rs тебе может майнинг засунуть в бинарь
В теории можно адекватно это делать:
1. Прибить хеши всех прямых и транзитивных зависимостей
2. Сравнивать их с хешами с гитхаба
3. Фейлить билд при отличиях
1. Прибить хеши всех прямых и транзитивных зависимостей
2. Сравнивать их с хешами с гитхаба
3. Фейлить билд при отличиях
EG
Тогда можно как-то гарантировать, что код, который используется, это тот же код, что и на гитхабе
EG
На практике я таких утилит пока не видел
RP
а на практике для упоротых есть вендоринг.
RP
и вообще на практике для людей, которые более-менее изучили раст, таких вопросов не стоит