Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implicit standard library dependencies #5003

Open
Ericson2314 opened this issue Feb 2, 2018 · 2 comments
Open

Implicit standard library dependencies #5003

Ericson2314 opened this issue Feb 2, 2018 · 2 comments
Labels
S-triage Status: This issue is waiting on initial triage. Z-build-std Nightly: build-std

Comments

@Ericson2314
Copy link
Contributor

Ericson2314 commented Feb 2, 2018

(Split from of rust-lang/rfcs#1133)

Assuming #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

  1. Any explicit stdlib deps at all means no implicit deps. Otherwise hard to reason about / teach. This is a simplification of what I proposed in the RFC.
  2. Need additional way to opt-out for core, as it has no dependencies whatsoever.
  3. All components (library, exes, tests, benches) get an implicit std dependency. (That would be all 3 of [dependencies] [dev-dependencies] and [build-dependencies].
  4. Would be cleaner to to do explicit core deps, but our hands our probably tied by back-compat.
  5. 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 in test being the only dep needed for both, precluding making the test-harness macro crate down the road.

CC @japaric @nrc

@stale
Copy link

stale bot commented Sep 17, 2018

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:

  • Is this still relevant?
  • If so, what is blocking it?
  • Is it known what could be done to help move this forward?

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!

@stale stale bot added the stale label Sep 17, 2018
@Ericson2314
Copy link
Contributor Author

Last I heard this sort of work might get priorized after the 2018 edition crunch time, so I'm just waiting for that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-triage Status: This issue is waiting on initial triage. Z-build-std Nightly: build-std
Projects
None yet
Development

No branches or pull requests

3 participants