Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
If any of this means I can drop os_str_bytes from clap, I want to know where I can help out. I know there is an approved RFC for "Extend Pattern API to OsStr" with no clear indication of why it stalled out since an implementation exists and a recent internals discussion on making OsStr like BStr.
For an example solution, if std was to be broken up into multiple crates using packages as namespaces. std::fs and std::process could be separate crates. You can then just run cargo tree -i std::fs and audit everything that relies on std::fs. Of course this has the problem that std wasn't designed for this and mixes concepts within the modules, we'd have to deal with the std::path crate having a fs feature flag (and the problems with propagating features), and problems with coherence / orphan rules.
I think at the end of the day this isn't a technical problem to be technologied out of, it's a social problem. So stuff like cargo-crev is, to me, a better approach—attempting to improve the social process of supply chain trust. Static analysis to aid in being a force multiplier for manual reviews is ofc helpful but I just don't know about involving automated static analysis in the front-line defense is helpful outside of coarse grained things ("are build.rs and proc_macros used?", even "there is no unsafe" might be too fine grained to have assurance for supply chain audits...)
I believe you mean capability based, like cap-std.
The editions system is extremely effective at allowing existing codebases to opt-in to breaking changes while eliminating the risk of fragmenting the ecosystem or requiring massive coordinated upgrades. Meanwhile, the integration with Cargo makes it so that new projects end up on the newest edition by default, steadily pushing the entire ecosystem forward. That there are limitations in what editions can change given these constraints is not a problem. In fact, the library team could be using editions more aggressively, it's just that they've (currently) chosen not to (e.g. https://github.com/rust-lang/rfcs/pull/3088 ).