Using hurl as a library

[nikeee]

I really love this tool. I loce it so much that I'd like to integrate it into some project. If I'm not mistaking, it's currently only a CLI tool (and a rust crate).

Sadly, most of my current projects that would benefit from this aren't written in rust. Would it be possible to somehow provide a version of this with FFI wrappers to the main part? Glancing at the source, this seems to be the function that would need to be wrapped:

hurl/packages/hurl/src/main.rs

Lines 61 to 69 in dab4006

	fn execute(
	filename: &str,
	contents: String,
	current_dir: &Path,
	cli_options: CliOptions,
	log_verbose: &impl Fn(&str),
	log_error_message: &impl Fn(bool, &str),
	progress: Option<Progress>,
	) -> HurlResult {

Also, are there non-statically linked parts?

[fabricereix]

Hello,
As crate, Hurl can be used "technically" as a library. But the APIs still needs to be improved.
Relating to non-statically linked parts, Hurl relies on libcurl and libxml.

[fabricereix]

From what language you would like to call the Hurl API? Python?
If you can manage something, we will be interested by your feedback.

[nikeee]

It's currently .NET, which can consume exported C functions. I'm not that much into rust, but I assume that this would require some bindgen stuff.
In the application, I want to offer the user a way of defining HTTP request with any complexity. It seems like Hurl would fit the job pretty good, since requests can be chained and variables can be injected + captured.

Python would be interesting, too.

[tbolon]

FYI, in my case I am planning to write a .NET wrapper around the hurl process, which launch the hurl process then parse output.

But in my case I will run a lot of hurl files (think integration tests), so it makes sense to not reuse hurl and run multiple process in parallel. This way I also avoid any resource leak between the host and the multiple runs.

[nikeee]

I think the first step could be to just provide a create that exposes the above mentioned execute function.
From that on, we can create a create (possibly independent) that wraps this function + types to whatever someone needs.

[fabricereix]

We will try to create an example using Hurl as a lib.

[humphd]

This is something that would be cool to do with node.js and something like https://neon-bindings.com/. I'd love to see Hurl become more accessible to JS devs, many of whom aren't used to adding tools from outside the npm-ecosystem.

[fabricereix]

Yes, It would be good to see Hurl in the Browser/JS space.
It would useful for example to create a Hurl playground.

I initially thought about generating standard Web Assembly from Hurl Rust source code.
But HTTP requests have to be handled outside Web Assembly.

I don't know about https://neon-bindings.com.
It can be interesting to see how it handles these HTTP calls.

[jcamiel]

@humphd @fabricereix thinking about this issue, I'm wondering if publishing Hurl binaries to npm registry will not be sufficient (instead of building through Neon or WASM). For instance, dprint is a code formatter written in Rust and you can install it with cargo, brew, npm etc...:

$ brew install dprint
$ cargo install dprint
$ npm install dprint

On npm package, dprint is listed as "npm CLI distribution for dprint"

If we do the same with the existing Hurl binaries (publishing to npm), it should be sufficient to reach JS devs ?

[humphd]

This would be great, yes. Being able to install and run hurl via npm (e.g., having it get put in node_modules/.bin and being able to use it via npm scripts, like "test": "hurl --test ...") would accomplish what I'm after.

Looking at https://github.com/dprint/dprint/tree/main/deployment/npm seems to provide a good path forward. I tried installing it, and it does exactly what hurl should do: a binary is downloaded and npm can call it:

$ tree -a node_modules
node_modules
├── .bin
│   └── dprint -> ../dprint/bin.js
├── .package-lock.json
└── dprint
    ├── LICENSE
    ├── README.md
    ├── bin.js
    ├── dprint
    ├── info.json
    ├── install.js
    ├── install.ps1
    ├── install.sh
    ├── install_verify_checksum.js
    └── package.json

[humphd]

I filed #544 to deal with the npm install case, so I don't hijack this issue.

[jcamiel]

We've added a sample using Hurl as a library here /contrib/sample. We're using it now in the CI (see #972 ) to detect major changes in Hurl's crates API and can be used as a base for samples. I'm closing this issue for the moment.