You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nice to expose a library interface, to enable projects to build on top of xh along the lines of http-prompt. It would also help with #88.
This could be a pretty big change. We'd have to decide what to expose and commit to not breaking compatibility. Refactoring would become harder the more we expose.
It could help to have a consuming project that lives in the same repository (in a workspace).
At first glance, we might not have to expose that much, see how http-prompt calls it. But I haven't looked at other projects, and a richer API might be a lot more convenient.
Breaking the public interface after 1.0 would mean incrementing the major version number. I can think of a few approaches:
Get this in place before a 1.0 release and be very careful to provide something we can remain compatible with.
Be willing to increment the major version number even when nothing breaks for normal users of the tool.
Move most of the code into a new package (e.g. xh_core) that can increment its major version freely, while the xh package becomes a wrapper around it with more conservative versioning.
The text was updated successfully, but these errors were encountered:
Coming from #289, to be honest I didn't realize you were already using reqwest underneath. I liked the single line of xh :8080 rather than the multiline usage of reqwest, but it's likely not enough of a big deal to need to librarify xh.
It would be nice to expose a library interface, to enable projects to build on top of
xh
along the lines of http-prompt. It would also help with #88.This could be a pretty big change. We'd have to decide what to expose and commit to not breaking compatibility. Refactoring would become harder the more we expose.
Some concrete steps would be:
main
pub
topub(crate)
#[non_exhaustive]
to certain public enumsanyhow
It could help to have a consuming project that lives in the same repository (in a workspace).
At first glance, we might not have to expose that much, see how http-prompt calls it. But I haven't looked at other projects, and a richer API might be a lot more convenient.
Breaking the public interface after 1.0 would mean incrementing the major version number. I can think of a few approaches:
xh_core
) that can increment its major version freely, while thexh
package becomes a wrapper around it with more conservative versioning.The text was updated successfully, but these errors were encountered: