Crate evaluation for 2017-05-30: reqwest

Yes, I know about this issue, this is why I’ve asked if by a chance someone received an answer through other channels.

I was looking at macros, thinking there weren’t any, but apparently there is one that’s exported publicly. I suspect this is an error, so opened an issue. Hopefully that’s not breaking the rules :smile:

2 Likes

Something I’m wondering is if an async API is considered blocking for a stable release? And if so, how much of the current implementation we’re reviewing would change?

Apologies, I was on vacation without much internet/laptop.

I believe so, yes. There was supposely a reply to someone else who email Graham, claiming that an update was indeed coming, but that was a while ago, and still no update. Still, I wouldn't propose forcibly changing the author whatsoever.

The author of requests (with an "s") has emailed me that they'd be willing to let reqwest change to requests, so that's a possibility. I also had registered the agent crate name earlier, as another alternative.

Thanks for noticing! That's been fixed in 0.6.2.

I don't know if must block 1.0 or not. I would expect to add it soon, which would mean depending on unstable tokio and futures (besides of course the already unstable hyper). I'd also expect to provide both a synchronous and asynchronous Client, naming TBD, and so the name Client would probably need to be updated as well.

Actually, with regards to stabilizing without stabilizing hyper, I'm not certain how that will work. hyper cannot stabilize while Futures and Tokio still are unstable. Possibly reqwest could remove all publicly exported types that come from hyper, and thus exist one whatever version of hyper. This would mean making new types for StatusCode, HttpVersion, Method, and the whole headers module.

1 Like

Could those types be stabilized without stabilizing the rest of hyper?

There’s been discussion about pulling headers/status codes from hyper into separate crates, which is one way to stabilise them. I’m also keen on that idea personally.

2 Likes

I would be very keen for that as well. I’m just starting to extract part of an Iron web app into a framework agnostic helper, but realised that meant I’d have to pass status codes around as integers since I don’t want a hyper dependency there.

1 Like

While that is definitely the eventual goal, and we may be able to make some progress soonish, that still wouldn't be a stabilized crate immediately.

That's totally reasonable, and worth pointing out :slight_smile: It's an avenue to consider that gives us a more fine grained way to stabilise parts of the API and gives other libraries a fine grained way to depend on it.

I started going over the API guidelines checklist in preparation for the libs team meeting on Tuesday and it would be great to get some more eyes on it, since this is one of the biggest crates we have looked at so far. There is plenty more room for feedback. Please help!

https://public.etherpad-mozilla.org/p/rust-api-guidelines-reqwest

1 Like

Today the libs team along with our guests @seanmonstar, @KodrAus and @stephanbuys met to talk about the reqwest crate.

Discussion topics

When is it okay to use private types in the public API?

There are three cases where the reqwest public API refers to types that are private - meaning they cannot be named by any code outside of reqwest.

One of the three was unintentional and we just need to publicly expose the types involved (reqwest#105).

The other two cases were intentional but result in confusing rustdoc documentation. We will need to make changes to keep the intended behavior but make the rustdoc more easily understandable (hyper#1194 and reqwest#106). There may also be a way that rustdoc could improve this situation (rust#42323).

We will clarify these private-in-public patterns as an API guideline (guidelines#73).

Do &Error trait objects need to be Send and Sync?

It probably doesn't matter. For consistency with io::Error we will change this in reqwest (reqwest#107) and also clarify the applicable API guideline (guidelines#80).

Are the StatusCode and HttpVersion enums a compatibility hazard?

Yes. New HTTP status codes and versions will be added in the future and we would not want that to require a breaking change in hyper or reqwest.

Associated constants will be stable soon so we will switch to those (hyper#1195).

What are the stability implications of re-exporting types from hyper?

Reqwest would like to release a stable version. Currently reqwest re-exports the Method, StatusCode, and HttpVersion types from hyper, so it couldn't be stable until hyper is stable. Stable hyper is waiting on stable tokio. Stable tokio is not imminent.

We will resolve this by factoring some of the foundational types like StatusCode into a separate crate that can be stabilized sooner than all of hyper (hyper#1196).

How to deal with fallible methods on a builder that takes self by value?

The existing RequestBuilder was designed before Rust's question mark feature. It is a self-by-value builder with fallible methods that pretend to be infallible by stashing away an error until the request is about to be dispatched.

In today's Rust this would be more ergonomic as a &mut self builder with fallible methods (reqwest#108).

This calls for some API guidelines updates as well (guidelines#81 and guidelines#82 and guidelines#83).

What is the deal with html_root_url?

It is annoying and limited, and a small amount of tooling work could go a long way (rust#42300 and rust#42301).

Isn't there a better name for this crate?

No, reqwest is a great name.

Do we really want CI badges on crates.io?

Probably. But there is a lot of work we need to ask from the infrastructure team before the badges would be as meaningful as we would like. @sfackler will follow up.

Guideline improvements

5 Likes

Could this be done? As as casual user of the crate and talking to others about, referring to it as "Rust has this cool request package for HTTP, oh but you spell it R-E-Q-W-E-S-T" I think "requests" would be more ergonomic long term, since the owner of request doesn't want to give it up. I even found it a little awkward in the code to write reqwest::. My fingers naturally wanted to type request.

This also matches the name of the popular Python package requests.

In the video meeting, when it was brought up, many felt that reqwest was a better name. I can list the reasons people have given me (I’m not saying that it is objectively better, I questioned it too):

  • reqwest is a unique name, so it doesn’t get confused with request from JavaScript, or requests from Python.
  • Remembering to include an ‘s’ seemed just as arbitrary as remembering to spell with a ‘w’.
  • It’s already used by many, changing the name causes disruption, which would be fine if it were an immense win, but it doesn’t feel like it is.

In the meeting, it sounded like people liked most the ‘branding’ aspect of it being a unique name. But if anyone that was there (or otherwise) wants to share their opinion on why the name should remain, please share!

1 Like

is it worth highlighting a pronunciation like ‘rek west’ or ‘ree quest’ or something?

I don't super care what the name of this crate is, but I think I understand the position of the people who find "reqwest" more arbitrary than "requests": "requests" is a correctly-spelled English word, and that makes it much easier to type. When I just now tried to type "reqwest" at full speed, I produced "requew" before the "no, that's not right" signal got to my fingers.

Perhaps if I wrote a lot of code using this crate I would get used to it, but perhaps not.

("reqwest" is a 1-character substitution from a correctly spelled word, which is arguably the worst case for a speed typist. If it was called something that bore no resemblance at all to English, the motor programs for typing English quickly and accurately wouldn't be getting in the way.)

4 Likes

I can see how typing reqwest is frustrating, but I have to admit I have it engrained in my memory which library it is that I want, which I don’t think would be the case if it were called requests.

To make this a bit easier, you can extern crate reqwest as request; if you want.

Also in English Q is almost always followed by a U, so I too always find myself typing requ… before I have a chance to even think about it.

3 Likes

I too think that in a long run requests is a better name compared to reqwest. It’s simply has less mental burden and less surprising for new users. Difference between plural form of the word and misspelled one is quite substantial. Regarding uniqueness of the name, I don’t think it outweighs costs. As for search, personally I always add “rust” while searching crates and even now googling for “requests rust” gives crates.io as a first link.

5 Likes

I am glad we use reqwest, even if awkward to type, due to the uniqueness… makes it easy to search. Sucks so much when you get snake-related results when interested in the Python, or metal-related results when interested in the Rust.

4 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.