Crates.io meeting agenda 2019-06-13 20:00 UTC (Discord, 30 min)

[sgrif]

• [ ] Team membership review (@sgrif - 5 min)
• [ ] Response time elevation update (@sgrif - 5 min)
• [ ] When we remove crates from crates.io for DMCA/etc reasons, they also need to be removed from docs.rs (@carols10cents - 5 min)
  • Team managing docs.rs has a chatroom in #docs-rs
  • For now, manually ask QuietMisdreavous or Onur for removal. This feels like we should document this procedure, especially when we get advice from moz legal that's coming regarding takedowns
  • Filed issues (crates.io, docs.rs) for exploring potential "one-click" removal

[jsonnull]

Suggesting a discussion around the current crates.io frontend.

I know it's currently written in Ember, but I'm imagining there are difficulties around maintaining this and moving forward with new features.

I'd like to hear about the current state of the frontend, as well as any planned features. Hopefully we align on the current problem space and there's a mutual understanding of what we'd like to address going forward.

EDIT: This seems pretty relevant—https://github.com/rust-lang/crates-io-cargo-teams/issues/29

[Eh2406]

From the @rust-lang/cargo Team: dev-dependencies are annoying and almost useless in publish. (@Eh2406 - 10 min)

The inspiring case is that Cargo itself just added custom proc-macro ( https://github.com/rust-lang/cargo/pull/6900 ) to remove testing boilerplate. Now we can't publish to Crates.io, as path dependencies are not allowed, without publishing the small testing library. But noone using Cargo as a library needs to know that we use this dep for testing. We have checked carefully and Cargo only looks at dev-dependencies for the main project and completely ignores them for all dependencies. @alexcrichton, suggested that we comment that part of our Cargo.toml out before we publish, it works for his other projects. We are discussing ways to generalize that workflow.

Possible next steps:

• leave things as they are. Each project finds its own workaround as needed. Or.
• Cargo just removes dev-dependencies part of the Cargo.toml before giving it to Crates.io as part of publish for everyone. (This is not great as Crater uses that Cargo.toml, so it would be nice if testing worked from that file.) Or.
• Cargo adds a flag to strip dev-dependencies part of the Cargo.toml as part of publish only when asked to. (not great as it is an additional CLI flag to doc and maintain) Or.
• Crates.io and Cargo decide that you can publish with arbitrarily bad data in the dev-dependencies part of the Cargo.toml.

(@rust-lang/cargo comment if I missed something from our meeting.)

We wanted to get the Crates.io Teams thoughts about Cargo not telling you things that we historically did or about changing your policy. Specifically, do you use dev-dependencies for anything? If so would you mind not using them? Are you open to allowing path and git dependencies in the dev-dependencies for crates on the site?