In general I think it's a good practice to re-export types from dependencies that are part of a crate's public API. Currently, slog::Logger is part of the public API for ConfigLogging::to_logger and ServerBuilder::new, but is not re-exported from slog. So as a user of dropshot, if I want to make a function that wraps (in my case) ConfigLogging::to_logger, I have to specify slog as a direct dependency of my crate alongside dropshot and ensure I manually keep the versions of <my_crate> > slog synced with <my_crate> > dropshot > slog. It's not impossible, but it is tedious.
It looks like dropshot currently re-exports one dependency: semver. Could the same be done for slog?
Separate, but related: when re-exporting multiple dependent crates, you may want to put them in a module together. I've seen it called deps elsewhere. Your call!
Also, thanks for building dropshot! I'm really enjoying using it so far!
In general I think it's a good practice to re-export types from dependencies that are part of a crate's public API. Currently,
slog::Loggeris part of the public API forConfigLogging::to_loggerandServerBuilder::new, but is not re-exported fromslog. So as a user ofdropshot, if I want to make a function that wraps (in my case)ConfigLogging::to_logger, I have to specifyslogas a direct dependency of my crate alongsidedropshotand ensure I manually keep the versions of<my_crate> > slogsynced with<my_crate> > dropshot > slog. It's not impossible, but it is tedious.It looks like
dropshotcurrently re-exports one dependency:semver. Could the same be done forslog?Separate, but related: when re-exporting multiple dependent crates, you may want to put them in a module together. I've seen it called
depselsewhere. Your call!Also, thanks for building
dropshot! I'm really enjoying using it so far!