Include the registry field the index to support multiple registries

[jarhodes314]

When depending on a crate from git rather than crates.io, any transitive dependencies are listed as coming from the git repository. As a result, any transitive dependencies from crates.io via this repository cannot be reconciled with direct dependencies on the same crates. This then causes errors as cargo treats these dependencies as two separate crates with the same name.

This change adds support for the deps.registry field in the index to mark that dependencies originate from a different registry where relevant.

[dhovart]

Thanks for the PR. Tests just need to be adapted now that we have a more recent cargo version that supports namespaced features.

[jarhodes314]

I've now fixed the merge conflicts in the tests.

[dhovart]

Thank you! It would be nice to have a test case covering this as well, do you think you can provide that ?
I can also add one later if you want.

[jarhodes314]

I can try and add one, but I suspect the only simple way of testing multi registry support is to depend an a crate in a git repository that itself depends on crates from crates.io. I didn't focus on adding tests to this specifically as I needed to test the results of running this against my repos anyway, and a new test is likely more complicated than the added functionality. But I agree it's important to test that case.

To be honest, even with these changes, git dependencies are a bit of a mess. Once a dependency is coming from a registry (local or remote), cargo requires a checksum to be present in the index before unpacking the crate. This isn't the case with git dependencies, they currently have a checksum of null when downloaded in the local registry. This wasn't a problem for me as I already had a script wrapping cargo local-registry that could retrofit the sha256 hashes cargo uses to the downloaded index, but cargo local-registry should probably perform this itself as it's required.

I should probably do some further work to complete that functionality, and add a test where the registry field is non-null. I'll update you when this is done.,

[jarhodes314]

I've now added the missing functionality. This involves running generate_lockfile after removing any source replacement in the cargo config (required to remove any manually added checksums before resolving packages) and generating the checksum manually if it doesn't already exist. I've also added a test which mimics the existing tests, but contains a non-null value in the newly added registry field.

[jarhodes314]

I've created rust-lang/cargo#10939 since I don't think it's intentional behaviour that cargo requires a checksum for git dependencies. Therefore, I think this should not be merged at least until it has been determined whether that actually is a bug in cargo, at which point these changes could be partially reverted to not encompass checksums.

[dhovart]

Awesome, thank you. Subscribing to the issue you created.