hurl

Absolutely! I'm the maintainer of a small Open Source project [1] and this phrase makes me tickle. I totally get it that a maintainer doesn't want to merge some code, even if it's totally working. Is the new feature a niche case, or has if a wide audience? Is it aligned with the project goal/philosophy? Will it be easy to maintain/evolve/debug? Does it add unnecessary/unwanted dependencies? At the end of the day, the maintainer will be the person that have to work/support with this code. Please keep in mind that if you've spent an hour on a project, maintainers have have certainly spent hundreds if not thousands more time on it. [1]: https://github.com/Orange-OpenSource/hurl

> Surprisingly, the type wrapped by std::result::Result::Err doesn't need an Error bound: None of the errors types I create implements the trait Error. I'm just using simple enums with various variants and that's sufficient for me. The crates that I develop are mostly binary crate [1] so implementing the trait Error is maybe more prevalent in libraries crate. Reading the article, it feels a little overkill to me. I like the simple, straightforward approach (the one that you learn in the Book). I don't use anyhow also, I actively try to limit the dependencies I'm using. [1]: https://github.com/Orange-OpenSource/hurl

I tried Hurl after Insomnia went the way of Postman. The highlights you list were the strong drivers for testing it out. Where Hurl fell short was composing requests. Example: X.hurl response has authToken. Y.hurl uses authToken. Z.hurl uses authToken. There's no import ability[1], so you've got to use other tooling to copy X.hurl into Y.hurl and Z.hurl. Ultimately settled on Bruno. It's backed by readable text files[2] as well. The CLI works for scripting. And the GUI is familiar enough that I've managed to convert Postman holdouts at my dayjob. [1]: https://github.com/Orange-OpenSource/hurl/issues/1723 [2]: https://docs.usebruno.com/bru-language-samples.html