Version 1.0 public call. 👋🏼

[tomchristie]

Hiya team,

We're quickly narrowing in on a Version 1.0 release. ☺️ 🎉
I'd like to schedule a video call for interested parties in order to get some visibility onto...

• The Version 1.0 release plan, and deciding what will and will not make the cut.
• Outlining the project roadmap.
• Talking through sponsorship, contributions, and encode / project documentation.

If you'd be interested in joining a call could you comment against this issue and indicate availability...

• 9:00 am UTC, Weds 16th Oct. (a)
• 12:30 pm UTC, Weds 16th Oct. (b)
• 9:00 am UTC, Thurs 17th Oct. (c)
• 12:30 pm UTC, Thurs 17th Oct. (d)
• 9:00 am UTC, Fri 18th Oct. (e)
• 12:30 pm UTC, Fri 18th Oct. (f)

I'll update the ticket sometime on monday with a selected time and video link.

Thanks so much everyone for all your hard work and support. ✨🍰 ✨

(Paging @encode/maintainers & everyone else also.)

[RobertCraigie]

@tomchristie FYI the Version 1.0 release link is broken, it's pointing to this discussion instead of #3319

[tomchristie]

😅 Resolved.

[tomchristie]

(a,b,c,d,e,f)

[alexgmin]

(a,b,c,d,e,f)

Automatic time conversion to the viewer's timezone:
https://time.is/compare/0900_16_Oct_2024_in_UTC/ (a)
https://time.is/compare/1230_16_Oct_2024_in_UTC/ (b)
https://time.is/compare/0900_17_Oct_2024_in_UTC/ (c)
https://time.is/compare/1230_17_Oct_2024_in_UTC/ (d)
https://time.is/compare/0900_18_Oct_2024_in_UTC/ (e)
https://time.is/compare/1230_18_Oct_2024_in_UTC/ (f)

[RobertCraigie]

(a,b,c,d,e,f)

[ahopkins]

a, b, c, d

[RafaelWO]

d, f - but I cannot guarantee that I'll be able to attend

P.S. I'm not a contributor (yet) but I'm a happy and inspired user 🙂

[zanieb]

I can only do 12:30 slots, i.e. b, d, f with a preference for b, d.

I don't think it's a high priority for me to join, but interested in helping out.

[DarkPhily]

(e, f)

[alexgmin]

Since there are no updates I'm assuming it's not today?

[tomchristie]

Hi all...

Let's have a public call tomorrow, Thursday 17th... 12:30 UTC

https://time.is/compare/1230_17_Oct_2024_in_UTC/

On this meeting link...

https://meet.google.com/dst-jytb-mbe

[Kludex]

Can you record it? I don't think I'll be able to attend.

[tomchristie]

I'm not planning on recording this session, tho I'll keep it in mind for the future.
Will aim on taking more open calls, really helps to connect.
Perhaps see ya next time?

[zanieb]

I took some notes from the call — they're not perfect.

• Introductions
  • Tom Christie
  • Hugo
  • Alex Gomez Martin
  • Rafael
  • Zanie Blue
• 1.0 release
  • Announcement pull request for the release
    • Needs changelog
    • Context on why breaking changes are being made, e.g, the SSL API changes
    • Getting this further should help decisions on the changes
  • Is the SSL API correct?
    • In the current version we have the same interface as requests
    • We got rid of accepting various types and require an SSLContext specificially
    • It makes things like switching to truststore easier
    • It makes the API more coherent
    • Should the parameter be named ssl or ssl_context?
    • Should the parameter be named verify and take a bool still?
      • Would simplify migrations for users
  • Should we include more features based on a messaging perspective?
    • Usually it's no big deal to delay adding features but while we're
      making an announcement it could help encourage people to switch from requests
    • e.g., a full request timeout
  • Decreased dependency footprint
    • The async dependencies automatically install anyio and sniffio,
      but we don't need those by default
    • There's a pull request moving this to httpx[asyncio] or
      httpx[trio]
    • We should drop idna as a mandatory dependency
    • The entire dependency should be httpcore, certify, and,
      indirectly, h11
    • We should make httpcore and certify soft dependencies so they are
      only imported when they're used
    • Then httpx can be installed on platforms without SSL support i.e.
      javascript platforms
  • Stricter type checking
    • We're following the requests API in a bunch of places but we could
      constrain the types and support the same functionality
    • e.g., the proxy parameter can be a string, Url, or Proxy instance
    • e.g., the timeout parameter can be a float, tuple[float, ..], or a Timeout instance
    • e.g., the auth and headers parameters too
  • Should system proxies be on by default?
    • Always on by default right now, requires opt-out to disable
    • Should we make it opt-in instead?
  • We can be explicit about using semantic version
    • We can explicitly suggest 1.*
  • We should suggest style for imports
    • e.g., import httpx rather than from httpx import ...
    • Ensure that httpx modules are private so it's clear you shouldn't import them
• Feedback?
  • Alex
    • The main use-case is to set a simple timeout which should be easy to
      do, i.e., with an int or float
  • Hugo
    • Having a timeout at all is really important
    • I don't think there's any rush to release 1.0 but it seems like you're
      close
    • I think it's nice that the API is drop-in for main use-cases
  • Zanie
    • Maybe you use GitHub code search to see how people are using the
      verify parameter to guide that decision
    • An overall timeout seems really nice but I'd be wary of expanding
      scope of the releasesince the team is
      small
      • Actually, if you frame it as a breaking change for the default
        timeout behavior I think it makes more sense to put into 1.0 (as
        opposed to just a bigger announcement with more features)
      • Rust's lib has a overall timeout by default: https://docs.rs/reqwest/latest/reqwest/struct.ClientBuilder.html#method.timeout
      • They don't have a write timeout which is tough for us: Add option to set write timeout seanmonstar/reqwest#2403
    • It's not clear that tightening the API types is a better user experience and could cause churn
• Project process
  • e.g., someone asks for something -> it's implemented
  • Prefer to start with a discussion still
  • Design-led process
  • Behavioral changes should be led by documentation
  • Allows focus on behavior changes rather than implementation changes
• Sponsorships
  • Django Fellowships have a good model
  • We should have transparency about how money is spent
  • Target incomes for developers
  • Create part-time positions
• Overall project aims
  • How can we reduce the complexity of the stack?
    • Less different ways to do things
    • Minimal footprints to the stack you're working with
  • When you drop into lower-level aspects it should be consistent
  • HTTP toolkit not just a client
  • It'd be nice to have a punchy tagline that differentiates it from other
    libraries

[RafaelWO]

It'd be nice to have a punchy tagline that differentiates it from other
libraries

What do you think about "Your all-in-one Python HTTP toolkit"? Or "The" instead of "Your".

[zanieb]

A few things we didn't talk about but probably should

1. Are we going to do pre-releases? Betas?
2. Are we going to write a specific migration guide?
3. Are we adding warnings to a pre-1.0 release that explains the upcoming migration?