Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conveniance loader function #5

Open
aDotInTheVoid opened this issue Feb 24, 2022 · 4 comments
Open

Conveniance loader function #5

aDotInTheVoid opened this issue Feb 24, 2022 · 4 comments

Comments

@aDotInTheVoid
Copy link
Member

Do

https://github.com/awslabs/smithy-rs/blob/f7e1f0836eb59e29fad668f9b0b3ad682757b5af/tools/api-linter/src/cargo.rs#L78-L100

but here so anyone can use it.

Not sure if this should live here or a seperate crate?

@Enselic
Copy link
Member

Enselic commented Feb 24, 2022

My recommendation/personal preference would be to let this crate remain a pure mirror of rustdoc-json-types in rust-lang/rust without any extra stuff.

Just in case this thought of yours was initiated by Enselic/public-api#27: I was simply silly enough to assume 0.7.0 had not been released yet when I wrote it. I didn't think you would be that fast. Super super silly. Sorry :)

The rustdoc JSON is still too much of a moving target for it to make sense to be "nice" about it IMHO. At least for a low-level crate like this one. On higher level crates it might very well make sense to be a bit nicer. In any case, I think it is better to put effort into making progress on rustdoc JSON itself rather than making this crate bigger.

@aDotInTheVoid
Copy link
Member Author

I think if/when I do this it should be a different crate

@Boscop
Copy link

Boscop commented Oct 3, 2024

@aDotInTheVoid Thanks for the loader code :)
+1 I think it would make sense to have it in this crate.

@jalil-salame
Copy link
Contributor

I don't think it should be in this crate as there is a bit of complexity involved, in cargo-semver-checks we might want to move to simd_json for it's tape API, which allows us to parse the JSON once, extract the version, then use the correct rustdoc-types::Crate to deserialize that version (without parsing the JSON again).

simd_json is not 1.0 yet so I don't think rustdoc-types should depend on it. Maybe under a feature gate?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants