Самое большое количество зависимостей

How about no?

Это отсылка к Остину Пауэрсу?

Нет, это посыл на*** в мягкой форме.

Из Остина Пауэрса?

согласно статистике на libs.rs больше всего direct dependencies у вот этого крейта https://crates.io/crates/coreutils/0.0.16/dependencies

Номинирую

• https://github.com/openshift/oc, 180 строк в go.mod и
• https://github.com/prometheus/prometheus/ – 201 строка в go.mod

в текущих версиях

Ну вообще да, но фраза стала мемом, и по большей части утратила связь с источником.

нужно смотреть go.sum, где указан полный список зависимостей, включая indirect. вот, для примера, один из самых популярных проектов для работы с конфиг файлами viper

https://github.com/spf13/viper/blob/master/go.sum

1146 строк зависимостей. кудряво написан проект. они уже скоро 3 года как рожают решение для этой проблемы, но воз и ныне там https://github.com/spf13/viper/issues/887

для сравнения… мой проект на порядок сложнее и имеет 0 зависимостей https://github.com/ergo-services/ergo/blob/master/go.sum. просто нужно писать проект так, чтобы можно было подключать зависимости опционально. а для этого думать приходится. не все обременяют себя этим в наше время.

Я просто заглянул в librsvg ebuild и обомлел - там 263 crates-пакета перечисленно.

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

просто нужно писать проект так, чтобы можно было подключать зависимости опционально

Зачем?

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

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

Зачем так делать?

Или я чего-то не понимаю?

ОК, тогда oc — 2136 (https://github.com/spf13/viper/blob/master/go.sum), prometheus — 1305 (https://github.com/prometheus/prometheus/blob/main/go.sum), чуть больше viper’а.

Sorry, it looks like we were not able to load the page. Please make sure your network connection works and you are using an up-to-date browser. If the issue persists, please visit our issue tracker to report the problem.

Смотря что за пакеты. В alacritty 222 зависимости в Cargo.lock, но итоговый бинарь 6.2M.

Меня вот больше бесит, когда в один проект линкуется несколько (часто даже больше 2) версий одной и той же библиотеки.

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

Если тебе от этого будет спокойнее, то да.

В идеальном мире да.

Но! потенциально больше и дыр. Апстрим запросто может забить на некоторые проблемы, например: «не собирается со strict-aliasing? Не используй при сборке strict-aliasing.»

При большом количестве зависимостей неплохо бы следить за изменениями в них, да и при малом тоже. А когда каждая из них часто обновляется становится?

Или я чего-то не понимаю?

это. речь не о крайностях, а о разумной середине. люди впихивают зачастую либы, которые они используют на 1%. заканчивается это тем, что начинают городить костыли в тулчейнах для управления зависимостями. это я сейчас про rule v2 у golang говорю. они решили проблему с зависимостями для 0.001% сверхкрупных проектов, но создали проблему для остальных (чудовищно кривое решение, придуманное парой «студентов» в гугле, но затрагивающее всех гошников, кто релизит софт >= v2.*)

Обычно зависимости подключают, чтобы упростить жизнь разработчика

в го для этого придумали интерфейсы. это своего рода плагин. конкретно viper’у просто нужно нормально прорабоать интефейст транспорта, а потом уже запилить разные транспорты, реализующие этот интерфейс. кому какой нужен будет, такой и заинклудит, но не будет тащить в зависимости >1K внешних пакетов.

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

А со скольки процентов можно использовать ? И как ты проценты считаешь ? Glibc только избранным можно использовать , а то 1% можно и наскрести

Не удивлюсь, если некоторые подключают boost только ради функции trim.

в текущих версиях

Позвольте спросить. «Теку́щие» - это от слова current?

concatenate and display input

Скоро сложение двух чисел в библиотеках будет. При том в разных для каждой возможной пары

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

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

Это уже крайности. Если над проектом работает больше одного человека, обычно подобная глупость отсекается. Ну, во всяком случае так показывает моя практика. Например, в одном проекте на go, в котором я участвовал был случай, когда товарищ из команды подтянул здоровую библиотеку для работы с postgres, хотя нам от базы нужен был самый минимум. На очередном утреннем митапе встретились, обсудили, договорились, что конкретно в данном случае напишем этот участок кода самостоятельно.

нет смысла тратить время на такие каменты в попытках что-то объяснить. он все прекрасно понял, просто ему хочется внимания.

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

https://go.dev/ref/mod#go-sum-files

The go.sum file may contain hashes for multiple versions of a module. The go command may need to load go.mod files from multiple versions of a dependency in order to perform minimal version selection.

https://go.dev/ref/mod#minimal-version-selection

там сложный процесс вычисления зависимостей

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

Не удивлюсь, если некоторые подключают boost только ради функции trim.

Ну да, мы такие

Думаю, да, также как и «current time» — текущее время. Но это догадки, я не лингвист.

Ну например во FreeBSD зависимости для go/rust не опакечиваются самостоятельно - весь список зависимостей из Cargo.lock (и что там у go) добавляется в порт, поэтому их количество на стоимость поддержки не влияет, только на скорость сборки и возможность исправить уязвимость в какой-то там десятой транзитивной зависимости без необходимости того чтобы каждый автор каждого модуля на пути к ней выпустил новую версию с обновлённой зависимостью.

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

В gentoo так же, а с некоторого времени, похоже, и в один архив всё запихивается.

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

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

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

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

Растовики библиотеки как перчатки меняют

После каждой сборки проекта, да. Но т.к. сборка длится по 18 часов, то получается не очень часто.

В texlive так много пакетов, что он называется «дистрибутив». Даже базовая установка достаточно много чего тянет.

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

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

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

К слову, это всё равно может оказаться выгодно.

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

Всякое бывает.

К слову, это всё равно может оказаться выгодно.

Может. Но не когда у тебя для простого проекта три сотни мелких библиотек подтягиваются.