cargo package downloads dev dependencies

[retep998]

https://ci.appveyor.com/project/retep998/winapi-rs/build/1.0.717/job/h7ohqxbk9vjtrb7p

cargo package
   Packaging winapi v0.2.5 (file:///C:/projects/winapi-rs)
   Verifying winapi v0.2.5 (file:///C:/projects/winapi-rs)
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading winspool-sys v0.0.1
 Downloading dwrite-sys v0.2.0
 Downloading d3d9-sys v0.1.0
 Downloading d3d11-sys v0.1.0
 Downloading dsound-sys v0.0.1
 Downloading wevtapi-sys v0.0.1
 Downloading shlwapi-sys v0.0.1
 Downloading credui-sys v0.0.1
 Downloading advapi32-sys v0.2.0
 Downloading dwmapi-sys v0.1.0
 Downloading dxguid-sys v0.0.1
 Downloading psapi-sys v0.1.0
 Downloading crypt32-sys v0.2.0
 Downloading winhttp-sys v0.0.1
 Downloading winapi v0.2.5
 Downloading vssapi-sys v0.0.1
 Downloading ole32-sys v0.2.0
 Downloading odbc32-sys v0.0.1
 Downloading shell32-sys v0.1.1
 Downloading ktmw32-sys v0.1.0
 Downloading secur32-sys v0.2.0
 Downloading mpr-sys v0.1.0
 Downloading uuid-sys v0.1.2
 Downloading hid-sys v0.0.1
 Downloading d3dcompiler-sys v0.0.1
 Downloading ws2_32-sys v0.2.1
 Downloading kernel32-sys v0.2.1
 Downloading comdlg32-sys v0.0.1
 Downloading httpapi-sys v0.0.1
 Downloading gdi32-sys v0.2.0
 Downloading runtimeobject-sys v0.0.1
 Downloading oleaut32-sys v0.0.1
 Downloading d3d12-sys v0.0.1
 Downloading opengl32-sys v0.1.0
 Downloading netapi32-sys v0.0.1
 Downloading xinput-sys v0.0.1
 Downloading dxgi-sys v0.2.0
 Downloading d2d1-sys v0.0.1
 Downloading winmm-sys v0.2.0
 Downloading usp10-sys v0.0.1
 Downloading user32-sys v0.1.2
 Downloading winscard-sys v0.0.1
 Downloading setupapi-sys v0.0.1
 Downloading bcrypt-sys v0.0.1
 Downloading dbghelp-sys v0.2.0
 Downloading winapi-build v0.1.1
 Downloading comctl32-sys v0.0.1
   Compiling winapi v0.2.5 (file:///C:/projects/winapi-rs/target/package/winapi-0.2.5)

There's no need for it to be downloading those dev dependencies when doing cargo package.

[alexcrichton]

For anyone who wishes to tackle this, the problem here looks like this:

• As part of crate resolution, we resolve the entire graph of dependencies. This disregards information like what targets a dependency is activated for, whether it's a build/dev/normal dependency, etc. Resolution just assumes you literally include everything from everywhere.
• After resolution succeeds, we call get_resolved_packages which in turn calls get for all packages in the graph which will download each in turn.

The bug here is that we download everything regardless of whether we'll ever need it later on or not. The fundamental problem is that the filtering of what packages we really need happens as part of the backend in cargo_rustc. Ahead of time we don't actually know which packages are going to be needed or not.

Possible solutions include:

• Lazily download all packages. While cargo_rustc is building up the graph of what to compile we could just download any package on demand.
• Refactor out logic for calculating target dependencies. This would mean that where we currently download packages could use the backend's logic for filtering the list of packages to what we really need to download.
• ... others!

[briansmith]

When traveling, or when I have spotty internet connectivity, I want to be able to download all the packages so I have them offline, so I don't need internet connectivity. The all-upfront approach works better for this. So, it would be nice to continue, at least, to have some way of downloading all the dependent packages upfront (cargo offline). However, IMO the all-upfront behavior is a pretty good default.

[alexcrichton]

@briansmith cargo fetch should suffice for that now.