Comments (10)
I'll implement what I have in mind and we can see if it makes sense, to me it doesn't bother me if it is not merged :)
from cargo-public-api.
Thank you for the feedback! Looks to me like you are using the API just as intended; you are not using internals. In fact, the code you use is the same as the example code at the top-level docs: https://docs.rs/public-api/latest/public_api/
I'm not sure it makes sense to have an even higher level wrapper, but I don't want to shoot down this idea before having seen a PR with a concrete proposal :)
from cargo-public-api.
I think what could be done is moving cargo_public_api::Plain
to public_api::Plain
and placing the item formatter behind a impl fn
should be pretty straight forward
from cargo-public-api.
@Emilgardis That would make public-api crate depend on terminal color crates, and I'd rather not have the public API analyzer depend on colors. I also try to avoid Cargo features (i.e. I don't want it an optional dependency), because I think that complicates code/testing/development/maintenance too much. So the current setup is quite deliberate.
But maybe there is some aspect of this I am overlooking, so if you want to prototype a bit around it, feel free of course!
from cargo-public-api.
No it wouldn't as all the formatting would be controlled by the caller, it's possible to implement without any new dependencies!
from cargo-public-api.
Sounds like you have thought this through, please go ahead, looking forward to the PR! 😀
from cargo-public-api.
Oh I had no idea that was the intended use case :). I'm fine with the issue being closed though what I was basically thinking of doing is to make this method public and have it take in the Write
as a param: https://github.com/Enselic/cargo-public-api/blob/6c84ec97a2c4d7e8137bd872bf6fe39906e3855f/public-api/src/main.rs#L57-L65
from cargo-public-api.
yup, my initial comment is a bit unneccessary parsing through what is actually needed now, a convenience function like this makes sense.
from cargo-public-api.
I'm actually not sure it makes sense to put that helper in the public API, because in the near future, we might want to make the output more tree-like, to solve #36, #37 and #39. The larger the API surface we have, the more work it will be to make necessary adaptations to the API. I try to keep the API surface minimal, because any addition to it, however small, increases maintenance burden of this project, and spare time is a scarce resource. Keep in mind that we not only have to maintain the API surface itself, but also tests for the API surface.
(Sorry for spreading some negativity again)
I'm fine with the issue being closed
If that is the case, and if @Emilgardis is also OK with that, I think we should do that.
Thanks again @SUPERCILEX for bringing this up so we could discuss it though.
from cargo-public-api.
Aaaand thinking about this a bit more, I think this is more a documentation issue :D
from cargo-public-api.
Related Issues (20)
- Resolve `Self` to concrete type to avoid unnecessary diffs HOT 6
- Probable bug in `Builder::clear_toolchain` HOT 1
- Add check for presence of dependencies in the public API HOT 3
- Support sparse creates.io registry HOT 5
- `serenity:all` re-exports triggers endless RAM-eating loop HOT 8
- Failure with `nightly-2023-05-24`
- Generic type information missing for items in paths HOT 5
- Simplify diff when moving an item to a different inherent impl while changing it HOT 11
- Error if the library target name is different than the package name HOT 2
- Installation instructions on README can be clarified HOT 2
- Make error message more helpful when `rustup` is not in `PATH` HOT 15
- New `rustdoc-json` minor release? HOT 2
- Add binaries to the releases to support taiki-e/install-action HOT 5
- Diffing public API against a published crate with `[package] name` != `[lib] name` miscalculates the rustdoc JSON path and fails HOT 4
- Output JSON? HOT 7
- Bump minimum supported nightly version HOT 4
- Features in combination with diff HOT 13
- `constant literals have a type` error HOT 8
- [Status: Completed] Move project from https://github.com/Enselic/cargo-public-api to https://github.com/cargo-public-api/cargo-public-api HOT 1
- Unknown variant `lifetime_predicate` HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cargo-public-api.