Open Ericson2314 opened 6 years ago
As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.
I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?
The team would be especially grateful if such a comment included details such as:
Thank you for contributing!
(The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.)
If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!
Last I heard this sort of work might get priorized after the 2018 edition crunch time, so I'm just waiting for that.
(Split from of rust-lang/rfcs#1133)
Assuming https://github.com/rust-lang/cargo/issues/5002 shakes out in some fashion, we need to elaborate crates without explicit standard library dependencies to have them, so they can be practically used together with crates that do.
https://github.com/Ericson2314/rust-rfcs/blob/cargo-libstd/text/0000-cargo-libstd-awareness.md#implicit-dependencies was the section that covered this in my old RFC. I think it still reads fine but I'll double check and port over.
Key points to think about in any even
core
, as it has no dependencies whatsoever.std
dependency. (That would be all 3 of[dependencies]
[dev-dependencies]
and[build-dependencies]
.core
deps, but our hands our probably tied by back-compat.test
is a bit tricky because of the way it interacts with the built-in test harness. Ideally IMO they would both be normal crates, the harness a procedural macro of sorts. I don't want to grandfather intest
being the only dep needed for both, precluding making thetest-harness
macro crate down the road.CC @japaric @nrc