Generated qt crates depends on non-generated qt crates while generated exists.

[o01eg]

Could generated qt crates depends locally only on generated crates? There is a option --no-local-paths but it make all qt crates depends on version from crates.io.

With --no-local-paths:

qt-test000 v0.1.0 (file:///mnt/another/srcs/myPijul/qt-test000)
├── qt_core v0.2.2 (file:///mnt/another/srcs/myPijul/qt-test000/qt_core)
│   ├── cpp_utils v0.2.0
│   └── libc v0.2.32
├── qt_gui v0.2.2 (file:///mnt/another/srcs/myPijul/qt-test000/qt_gui)
│   ├── cpp_utils v0.2.0 (*)
│   ├── libc v0.2.32 (*)
│   └── qt_core v0.2.2
│       ├── cpp_utils v0.2.0 (*)
│       └── libc v0.2.32 (*)
├── qt_ui_tools v0.2.2 (file:///mnt/another/srcs/myPijul/qt-test000/qt_ui_tools)
│   ├── cpp_utils v0.2.0 (*)
│   ├── libc v0.2.32 (*)
│   ├── qt_core v0.2.2 (*)
│   ├── qt_gui v0.2.2
│   │   ├── cpp_utils v0.2.0 (*)
│   │   ├── libc v0.2.32 (*)
│   │   └── qt_core v0.2.2 (*)
│   └── qt_widgets v0.2.2
│       ├── cpp_utils v0.2.0 (*)
│       ├── libc v0.2.32 (*)
│       ├── qt_core v0.2.2 (*)
│       └── qt_gui v0.2.2 (*)
└── qt_widgets v0.2.2 (file:///mnt/another/srcs/myPijul/qt-test000/qt_widgets)
    ├── cpp_utils v0.2.0 (*)
    ├── libc v0.2.32 (*)
    ├── qt_core v0.2.2 (*)
    └── qt_gui v0.2.2 (*)

Without:

qt-test000 v0.1.0 (file:///mnt/another/srcs/myPijul/qt-test000)
├── qt_core v0.2.2 (file:///mnt/another/srcs/myPijul/qt-test000/qt_core)
│   ├── cpp_utils v0.2.0 (file:///tmp/cpp_to_rust/cpp_to_rust/cpp_utils)
│   └── libc v0.2.31
├── qt_gui v0.2.2 (file:///mnt/another/srcs/myPijul/qt-test000/qt_gui)
│   ├── cpp_utils v0.2.0 (file:///tmp/cpp_to_rust/cpp_to_rust/cpp_utils) (*)
│   ├── libc v0.2.31 (*)
│   └── qt_core v0.2.2 (file:///mnt/another/srcs/myPijul/qt-test000/qt_core) (*)
├── qt_ui_tools v0.2.2 (file:///mnt/another/srcs/myPijul/qt-test000/qt_ui_tools)
│   ├── cpp_utils v0.2.0 (file:///tmp/cpp_to_rust/cpp_to_rust/cpp_utils) (*)
│   ├── libc v0.2.31 (*)
│   ├── qt_core v0.2.2 (file:///mnt/another/srcs/myPijul/qt-test000/qt_core) (*)
│   ├── qt_gui v0.2.2 (file:///mnt/another/srcs/myPijul/qt-test000/qt_gui) (*)
│   └── qt_widgets v0.2.2 (file:///mnt/another/srcs/myPijul/qt-test000/qt_widgets)
│       ├── cpp_utils v0.2.0 (file:///tmp/cpp_to_rust/cpp_to_rust/cpp_utils) (*)
│       ├── libc v0.2.31 (*)
│       ├── qt_core v0.2.2 (file:///mnt/another/srcs/myPijul/qt-test000/qt_core) (*)
│       └── qt_gui v0.2.2 (file:///mnt/another/srcs/myPijul/qt-test000/qt_gui) (*)
└── qt_widgets v0.2.2 (file:///mnt/another/srcs/myPijul/qt-test000/qt_widgets) (*)

Is it possible to use cpp_utils from crates.io while qt crates be generated?

[Riateche]

There is currently no such feature, but we should probably add it. If you need a workaround, you can manually remove the path corresponding to cpp_utils from Cargo.toml of the generated crates.

[Riateche]

This doesn't seem very useful with the currently recommended workflow. When generating the crate, ritual assumes that the API of cpp_core matches the cpp_core in the repository. If it doesn't match, the generated crates just won't build. Having a path in Cargo.toml doesn't really hurt: if the path is not available, cargo will switch over to the crates.io version automatically. All paths are also stripped from Cargo.toml when publishing a crate.