Switch to cargo metadata

[tmvkrpxl0]

Hello, I've been using cargo-gpu and trying to contribute for a while. and I found issue #37 which seemed easy enough.
In this pr, I removed 2 few tests checking if package is correctly parsed, because those were now handled by external crate cargo_metadata which is maintained by oli-obk, although I'm just trusting them to maintain this properly.
It now uses shorter revision. Previously, the tests used revision 82a0f but now it's 82a0f69008414f51d59184763146caa6850ac588, which is much longer. and I think same would happen to directory names in cache. so users updating would redownload directories, unless we find a way to check if those are same revisions.
I expect some bugs to present in this PR, and I'm open for more changes. This is just initial proposal.

[tmvkrpxl0]

I also did cargo update, is that ok?

[tombh]

This looks great, thank you for taking the time to look into this. It relates to #55 right?

I think this is a good approach. I had already started doing something similar in this function: get_cargo_toml_as_json() (notice the TODO which exactly relates to the work your doing in this PR). I wonder if you could refactor your approach into that function?

[tombh]

It might be more accurate to say that we're running cargo_metadata::MetadataCommand now right?

[tmvkrpxl0]

It was to follow this line
https://github.com/Rust-GPU/cargo-gpu/pull/66/files#diff-e50e99da00483f62292c3fcb50fdea5e75b82a3d8506d159cc26e1bca432c282L208
It says it's running cargo tree like terminal command and I believe it should still print it this way?

[tmvkrpxl0]

Why did the CI failed? it looks to be something about spirv-tools build error. Is it related to this pr?

[tombh]

The Windows build certainly looks like it's having a problem building spirv-tools-sys, it could be a temporary thing, so worth running again just to be sure.

But the Linux builds against older versions of rust-gpu (0.8.0 and 0.9.0) are erroring because they can't checkout the rust-gpu repo at the correct commit. It looks like your changes are preventing the Git checkout, I'm not sure why. Perhaps it's something to do with checking out a version number instead of a SHA hash?

[tmvkrpxl0]

Currently it works for local project as well but I now have new issue: #68
Why it has to be this hard to use this for my own project....

[tmvkrpxl0]

Should we bump minor version from 0.1.0 to 0.1.1 after this pr?

[tmvkrpxl0]

I created a bandaid fix for #68 so that it would ignore RUSTC environment variable set from outside like workspace root.

[Firestar99]

Could I take over this PR / cherry-pick it into mine? I'm currently refactoring the inner workings of cargo gpu a lot, and while our PRs don't strictly overlap, I see an opportunity to completely remove the git clone we currently do and reuse the checkout / download cargo already does for us. I just need the manifest_path only cargo metadata provides, see #69 (comment) for context.
Give me a 👍 if you're ok with that, I just don't want to waste your time fixing up this PR if I may replace it soon after.

[tmvkrpxl0]

@Firestar99 Yeah sure, I'll still be included in co-author in those cherry picks, right?

[Firestar99]

of course!

[Firestar99]

closed in favor if #69

Thanks for allowing me to steal your PR :D