"New questions in Favorite Tags filter for Jul 7 - Stack Exchange" -  да ладно, мне вон только с rust тега каждый день по 15-30 вопросов падает в почту. Самые общие давно разобраны, но народ потихоньку углубляется в разную специфику, окружения, библиотеки, тп

1587 катит?

За что ж Вы так внезапно?! Я поперхнулся чаем — чуть ноут не залил! 🤣

Задал вопрос в новой области которая стрельнула (кросскомпиляция с линукса на винду в расте)

Новые направления приносят много если выстрелят

Но вообще такой цели не преследовал

kvark: по мне так гитхаб со своими дискуссиями вбил им огромный гвозь в гроб

На мой взгляд дискуссии и близко не стоят с SO. Дискуссии это больше гвоздь в гроб всяким discourse

Хотя у гитхаба вроде и Q&A в виде экспериментов вроде был

Ладно. В основном Rust чате на меня ругаются, поэтому попытаю счастье тут.

Вопрос вот какой. У меня в JHT(проект процедурного моделирования компьютерной графики с помощью скриптового языка) есть система скриптования. Причем, модульная. Модули могут подключать другие модули. Но, соответственно, нет пакетного менеджера. То есть на текущий момент вся система модулей просто сидит в одной рутовой директории, которую указывает пользователь.

Я подумывал организовать пакетную систему поверх самого Cargo, но похоже, что из dependency-крейтов так просто ресурсы(скриптовые файлы, то есть) не вытенешь. За разработку своего пакетного менеджера я наверное не возьмусь, слишком тяжелая задача. С другой стороны, не думаю, что и пакетов будет так уж много.

Чет даже не знаю, что с этим делать. Может обычные git сабмодули использовать. Но это не очень удобно.

А эта модульная система должна масштабироваться? Какие требования к проекту являются причиной размышлений о пакетном менеджере?

а что такого сложного в пакетном менеджере?

Ну, там как предполагается. Само скриптовое API оно только совсем базовые штуки позволяет рисовать(палочки, шарики). Предполагается, что на их основе можно будет делать более комплексные объекты. Например, можно написать скриптовый "фреймворк", который будет рисовать разные виды растений. Потом разработчик игры "подключает" себе этот фреймворк, как-то его уже в своих локальных скриптах настраивает, и получает ассеты конкретных цветов и деревьев для конкретной игры. Вот как организовать это самое подклчючение я и думаю.

Слишком большого масштабирования наверное пока не планируется, но какой-то такой минимум хотелось бы иметь.

В общем-то ничего сложного, просто очень много возни. Я боюсь, это может несколько месяцев занять, а это сейчас не самое приоритетное.

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

Но вообще минимальная реализация на основе git не звучит сложно

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

Карго не для этого предназначен

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

Возможно какой-то общественный cdn + набор утилит юзабельных из build.rs