Как разделить Cargo.toml на несколько файлов?

Question

[Артём]

В самом языке Rust есть атрибут include, который вставляет текст из другого файла. Мне нужен такой же функционал в Cargo.toml, потому что я хочу использовать web-sys crate. У него много фич, и я хочу их организовать по разным файлам, чтобы не запутаться. Или лучше так несколько раз объявить?:

[dependecies.web-sys]
features = [
  "featuretype0_foo",
  "featuretype0_bar",
]

[dependecies.web-sys]
features = [
  "featuretype1_foo",
  "featuretype1_bar",
]

Правда я не знаю или можно так. Но даже если можно то очень хочется по разным файлам разложить всё равно

Answer 1

[Василий Банников]

Разделить Cargo.toml на несколько файлов нельзя.
Разделять features на несколько штук я тоже не рекомендую - читать это будет сложно с учётом того, сколько фич в web-sys и как ты скорее всего будешь их добавлять

В самом web-sys это автогенеренный код, но всё же:
https://github.com/rustwasm/wasm-bindgen/blob/main...

Comments

[Артём]

Ясно, найду какой-нибудь 3rd-party tool

А что вы хотели сказать своим "но всё же"? То что это автоген, но это один файл? Или то что фичи не разделены как у меня в примере? Или и то и другое?

[Василий Банников]

Артём, и то и то.
А зачем усложнять всё при помощи сторонних инструментов?
Чтобы IDE совсем развалилась от невозможности определить используемые фичи?

[Артём]

Василий Банников, Та не. Я не хотел прям заменить Cargo.toml чем-то. В cargo вроде есть фича build scripts, но она вроде только для компиляции других языков. Я хочу использовать что-то типо того для генерации этого файла (то есть я на расте самом напишу генерацию этого файла). Да и IDE я пока не использую, всё с телефона, Acode не славиться фичами, которые могут развалиться от этого

Мда, получается я свой будущий код обозвал 3-rd party tool-ом). На то оно и подсознание, чтобы ошибаться в неважных деталях, в угоду оптимизированного решения проблем

[Василий Банников]

Артём, не выйдет, тк build.rs запускается в рамках проекта => Cargo.toml уже должен быть сформирован.

Вообще ты можешь просто разделить свой проект на несколько крейтов, для каждого из которых будет свой Cargo.toml с нужным набором фич.
Только нужно будет задуматься, какие именно вещи нужно выносить

[Артём]

Звучит как ленивое решение. У меня есть build.sh (bash script) в папке с проектом (потому что из rust в js нельзя одним cargo b обойтись), которым я постоянно всё выполняю. Я просто добавлю там строчку на выполнение крейта, который сгенерирует мне мой Cargo.toml. Правда нужно будет понять как это сделать. Зато опыт появится в парсинге, потом легче будет осваивать процедурные макросы. Они мне нужны, потому что и в самом rust не хватает вкуснятин, например перегрузки через постфиксы, я не хочу делать модуль, имя которого на самом деле является именем функции, а функции в нём - постфиксами. Типа так не хочу:

mod overloaded_fn {
  pub fn args_layout_0(u: u32) {}
  pub fn args_layout_1(f: f32) {}
}

Правда я не знаю где мне перегрузка понадобится, и понадобится ли вообще. Ведь Rust смог меня убедить в ненадобности наследования.
Ну или хотя бы для того, чтобы сделать улучшенный use. Например если нужно использовать все из модуля, кроме одного item-а, нет синтаксиса, чтобы перечислить только его, а не все те, которые тебе нужны. Ну и если половину item-ов нужно использовать, то можно маркеры перед ними поставить, и use по маркеру использовать. И эти маркеры можно отдельно определить, как методы/функции определяются отдельно от структур, в impl блоке, чтобы не засорять восприятие. Думаю в надобности этого Rust меня точно не переубедит

[Василий Банников]

Артём, что-то какие-то стрёмные штуки ты предлагаешь, если честно)
Ещё предложи при помощи регулярок фильтровать, что ты хочешь импортировать

[Артём]

Василий Банников, я так и знал, что регулярками стебать меня будешь) Не, регулярки это перебор. Маркеры дают универсализм. Хотя я понял что можно без них обойтись. Можно просто создать модуль `a` с публичным use всего что мне нужно в модуле `b`, а потом в модуле `b`, сделать use одним астериксом (*) из модуля `a`. Так тонна use-ов будут вынесена в другой модуль, и не будет мазолить глаза

[Василий Банников]

Артём, ага. И так уже делают - prelude называется

[Артём]

Василий Банников,

use {
    bar,
    foo as namespace::foo,
    baz
};

А такое реализовать с помощю макросов ты не считаешь стрёмной идеей?
Эквивалент без макроса:

use {
    bar,
    baz,
};
mod namespace {
    pub use foo;
}

На каждый такой namespace в 3 раза больше строк уходит

[Василий Банников]

Артём, а нафига?
Почему бы просто тогда не написать
as namespace_foo

[Артём]

Василий Банников, Это ленивое и C-подобное решение.
Если у тебя есть:

mod namespace {
    fn foo() {}
    bar
    baz
}

Тогда ты можешь импортнуть всё одним астериксом.
А если у тебя то, что ты предлжожил (namespace_foo, namespace_bar, namespace_baz), то это уже какой-то неудобный C. Тогда уже нужны регулярки, ахаха.
Проблема в масштабировании. И дело не в синтаксисе — как получить доступ к foo —, а в семантике — что это значит и что с этим можно затем будет сделать

[Василий Банников]

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

[Артём]

Василий Банников, пока нет, но интуитивно кажеться полезным. Я в свой лист идей это записал, как возникнет потребность, реализую, и если не забуду, напишу где понадобилось это

[Василий Банников]

Артём, если нет примера, то, скорее всего, нужды в этом нет )
Вообще подобный код, когда нужно много реэкспортов в модули с другими именами, или вообще в другую иерархию модулей возникает, как правило, при сгенерированном коде.
Так, например, tonic делает.
В реальной ситуации ты врядли будешь делать реэкспорты с переименованием в принципе.

[Артём]

Василий Банников, А что если сделать автогенерацию trait-ов, типа IntoSafe? Скорее конвертация опасных и не пригодных для &dyn SomeUnsafeTrait. А ещё, почему не сделать подержку синтаксиса &dyn Foo + Bar? Эти то идеи надеюсь очевидно бьют по репутации Rust) Потому что забивать пространство имен этой фигнёй из-за бедности фич rust-а не очень приятно

Я бы даже сделал макрос по первой идее такой, что тебе не прийдётся писать другое имя trait-а. Надо создать макрос отдельный для генерации safe trait-а, потому что это сложный процесс, но всё же где-то шаблонности можно сократить (Потому что список restrictions не бесконечный) и автоматизировать генерацию. И ещё один макрос, который вводит специальный синтаксис типа &dyn safe Into

[Василий Банников]

Артём,

А что если сделать автогенерацию trait-ов, типа IntoSafe?

Что за IntoSafe?

Скорее конвертация опасных и не пригодных для &dyn SomeUnsafeTrait.

Что?

А ещё, почему не сделать подержку синтаксиса $dyn Foo + Bar?

Что ещё за $dyn? Вообще dyn для комбинации трейтов можно использовать.

Эти то идеи надеюсь очевидно бьют по репутации Rust)

Какие идеи? По какой репутации?

Какие макросы? что? зачем?

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

[Артём]

Василий Банников, Я имел ввиду генерацию object safe трейтов, на основе Into например, чтобы можно было использовать в trait object-aх. 2-ое просто опечатка, я имел в виду &dyn NonAutoTrait + NonAutoTrait2

[Василий Банников]

Артём,

Я имел ввиду генерацию object safe трейтов, на основе Into например

blanket impl в помощь.
А в язык такое встраивать не будут, тк это не zero cost

[Артём]

Василий Банников, И слава богу, я не хочу чтоб rust превратился в java. Оставлять выбор за программистом, какой трейт использовать, это хорошо. Но я просто хотел что-то типо автоматической конвертации не object safe трейта в object safe трейт без многословности так сказать. Я хотел бы чтобы с точки зрения дизайна языка это было чуть лучше

[Василий Банников]

Артём,

Но я просто хотел что-то типо автоматической конвертации не object safe трейта в object safe трейт без многословности так сказать.

В общем случае это сделать очень сложно.
Для частных случаев типа Into не вижу проблем просто делать blanket impl - он и так очень мало слов требует.