Our approach to index usage might need revision

[kentfredric]

It seems that, due to having only an index and repository that is built from installed packages, cargo is put at a disadvantage.

It seems that, under our eclass tooling, if a package declares an optional, or target specific dependency, cargo ends up requiring that package is installed, in order to provide merely the index data.

And even though this means the Cargo.lock file is updated to show these, they're not actually used .....

But this is enough to break things like cargo package, because it has to fetch the index data for all optional dependencies :/

[kentfredric]

It may even be worth having a package like dev-rust/crate-index or something that provides the analogous crate cache data. Idk.

[kentfredric]

I've found in general that in order to stumble into this problem as stated, you have to have some kind of binary asset in the build space.

Namely:

• Any Kind of example what so ever, no matter how many lines of code ( even 0-byte files called "*.rs" in examples/ is enough to trip this )
• Any kind of bin target what so ever ( eg: src/main.rs, or any bin/* or anything else mentioned in Cargo.toml

I've gotten around these limitations in general by simply nuking all binary assets that would be installed.

So far they're mostly examples, and the `bin''s they provide are pretty much not necessary.

How we'll handle actual examples and actual installed binaries will be... fun.