refactor: keep only trait in prelude

[wyfo]

The current prelude exposes all the types of the API. This is considered as a bad practice, as many of these names are quite common and could conflict. Most of the popular crate using prelude are only putting traits in it (plus some types with particular names).
These PR removes all types from the prelude, and put the main ones directly in the root.

[wyfo]

Following a discussion with @milyin.
Don't hesitate to ping other people interested in it.

@Mallets

[milyin]

I don't think that we have to be such conservative for prelude. Zenoh is big, but not as big, as e.g. rust standard library. From my point of view the goal of prelude should be to allow user to import only prelude::* and still have access to key zenoh functionality.

One of possible solutions could be like this:

pub mod prelude {
   pub mod traits {
     // reexport all the traits
   }
   pub mod types {
    // list here the big API element which we consider as core API
   }
   mod ztypes { // !!! not public !!!
    // exactly same as types, but commonly used names prefixed with Z: Err is ZErr, result is ZResult
   }
   pub use traits::*;
   pub use ztypes::*;
}
pub use prelude::types::*;

With this scheme we don't need to think too much what to include to prelude and what to include to root and what do not. Variants of usage:

use zenoh::prelude::*;
Config config;
let session = zopen(config, ...);
let subscriber = session.declare_subscliber(...);

use zenoh::prelude::traits::*;
zenoh::Config config;
let session = zenoh::open(config, ...);
let subscriber = session.declare_subscliber(...);

use zenoh::SessionDeclarations; // for trait `declare_subscriber`
zenoh::Config config;
let session = zenoh::open(config, ...);
let subscriber = session.declare_subscliber(...);

[wyfo]

See https://www.reddit.com/r/rust/comments/1cle18j/to_prelude_or_to_not_to_prelude/ as well as https://users.rust-lang.org/t/to-use-prelude-or-to-not-to-use-prelude-that-is-the-question/110855

[fuzzypixelz]

@wyfo Please change the base branch to dev/1.0.0 as protocol_changes is no longer the development branch.

[Mallets]

I'm not against but not 100% convinced wether it's a good idea to export all those types directly under zenoh::*. @milyin any opinion?

[wyfo]

Being able to write zenoh::Result/zenoh::Error is kind of mandatory IMO.
Also a lot of common english names, you may not want to import them directly, but use the module instead, for example zenoh::Session, or zenoh::Priority. I think it's more convenient for the user (in my own code, I think I would use zenoh::Session more than Session).

[Mallets]

I agree that some user may prefer zenoh::Session to just Session. My point is more on what do we decide to put in the root? And what not? E.g., Session, Result, Error make sense to be in the root but I'm not sure about Priority (which is just taken as an example here). Is Priority really a first class type to be exported in the root? Are we going to put all types in the root loosing any kind of hierarchy/grouping?

[wyfo]

I can split the PR in two, one for the prelude, and one draft for the putting the types into the root. The only issue is about imports in the examples.

[milyin]

I agree that this reexport to root should be shorter. Otherwise we'll be drowned in root types. I'd keep only commonly used functions, like open, scout, commonly used types types like Result and Error and types with the name same as it's module, e.g. KeyExpr, Session, etc. to avoid repeating like zenoh::session::Session. But for example it's important to not reexportQuery to force user to write use zenoh::queryable::Query and let him immediately see that this is unrelated to same-named query module.

I agree that better to split it to 2 PRs: one for prelude and one for global reexport

[wyfo]

About imports from zenoh dependencies in tests, I didn't write them but used my IDE auto-import. I don't think it matters a lot in tests, as it's not public code, but I can modify them if wanted

[Mallets]

About imports from zenoh dependencies in tests, I didn't write them but used my IDE auto-import. I don't think it matters a lot in tests, as it's not public code, but I can modify them if wanted

I agree that it doesn't matter a lot in the tests but it would be good to verify they can actually be imported from zenoh without requiring importing the types from other crates.

[wyfo]

I've rebased the PR and updated test imports

[wyfo]

The error in the CI is a false positive, Value is used in zenoh/tests/session.rs in line 172
I don't know what to do. When I execute the command on my computer, there is no error.

[fuzzypixelz]

The error in the CI is a false positive, Value is used in zenoh/tests/session.rs in line 172 I don't know what to do. When I execute the command on my computer, there is no error.

@wyfo You're experiencing the wonderful phenomenon of "Shadow Merges" in GitHub pull requests. The CI does not run on your branch as such, but on different version of it where a git merge origin/dev/1.0.0 has been executed, yielding a different HEAD. This is done in the actions/checkout action.

I can confirm that someone on dev/1.0.0 removed the usage of Value in line 172. You should rebase/merge.

[wyfo]

I don't know why the CI fails this time. @fuzzypixelz do you have an idea?