"pub extern crate" for all dependencies

[vitiral]

Summary

This is to discuss whether all dependencies sould use pub extern crate. This is the current strategy for ergo and regardless of the decision for quicli I would like to understand the arguments from the various angles.

Argument FOR

quicli is a "wrapper/conglomeration" crate. It's goal is to pull parts of the ecosystem together into a unified API and make it simple to use them. It's secondary goal is to "get out of the way" when users want more complexity, and even provide paths for not using quicli at all.

A usecase might be needing to use clap directly. The current (suggested) path is that you have to add clap to your Cargo.toml. However, clap is directly exported (as part of the public api) of structopt, so all that would be really necessary is use quicli::structopt::clap.

Edit: Another advantage is that pub extern crate makes the external crate docs more accessible in the autogenerated docs

Argument AGAINST

I'll just copy @killercup's comment from here

Not sure this is a good idea. If you are honestly using clap in your crate for anything, you should probably add it to your Cargo.toml and use the same version as quicli. That's more obvious to any contributors including your future self. I'd be interested in what other think about this.

I'll just add that publically exporting the crate means that API breakages in external crates could theoretically mean that your API changed.

Unresolved Questions

I disagree about the API change from external crates -- I think if the user doesn't want the wrapped crate to be upgraded they should have to pin it in some way. However, I currently don't know how to do this so documenting how to pin dependencies is an important unknown.

[CAD97]

If the dependency specifies crate = ">1.0.0, <3.0.0" and that's the only restriction, cargo will resolve to 2.∞.∞. If the binary specifies crate = "^1.0", cargo will unify the requirement to >1.0.0, <3.0.0, ^1.0.0 which is the equivalent of ^1.0.0.

The difference between the ergo "crate collection" and the quicli crate is that while ergo is just reexporting the crates it's bundling, quicli is reexporting the contents of the crates that it uses. In ergo, you're still using the the crates that it reexports. In quicli, though, though you are using the functionality of the crates quicli builds on, the existence of those crates is a secret; the reexported functionality is the functionality that quicli provides.

ergo is the only kind of crate where I'd say a crate = "*" bound is appropriate; it shouldn't be bounding the versions of the libraries the client binaries are using. But if the binary has to specify its (transitive) ergo dependencies anyway in order to specify their version, what's the point of having ergo in the first place? 🤔 I think ergo's mindset works for binaries which use the lockfile, but libraries shouldn't be using it if it's taking that lighter stance towards stability of "you specify my dependency's version requirements for me".