* Package name    : httpcore2
  Version         : 2.3.0
  Upstream Contact: Pydantic Services Inc.
* URL             : https://pypi.org/project/httpcore2/
* License         : BSD-3
  Programming Lang: Python
  Description     : Provides a minimal low-level HTTP client.

It does not provide any high level model abstractions over the API,
does not handle redirects, multipart uploads, building authentication
headers, transparent HTTP caching, URL parsing, session cookie
handling, content or charset decoding, handling JSON, environment
based configuration defaults, or any of that Jazz.

Dependency for httpx2, which is a dependency of Starlette.

Hello Matheus

Am 09.06.26 um 03:42 schrieb Matheus Polkorny:

this library is build from the same source as the httpx2 library, no
need to create another source package.

Source is homed under
https://github.com/pydantic/httpx2/tree/main/src/httpcore2.

I'd add the information it's done in Python.

'Provides a minimal low-level HTTP Python client library'
later long description would fit perfectly.

Some things HTTP Core does do:
.
   * Sending HTTP requests.
   * Thread-safe / task-safe connection pooling.
   * HTTP(S) proxy & SOCKS proxy support.
   * Supports HTTP/1.1 and HTTP/2.
   * Provides both sync and async interfaces.
   * Async backend support for asyncio and trio.

Yes, but still not a reason to create another source package. I'd close
this ITP and only focus on the other one.

I'm willing to sponsor your work.

Has a discussion been had within the Debian python team and the
maintainers of the existing httpcore and httpx packages of which fork
they want to follow going forward?

If that discussion hasn't occurred, it would be worth having to
determine if we should have a single httpx (or httpx2) package which
provides httpx2 (or httpx). [If it has occurred, it would be useful to
link to a summary in the ITP bugs and possibly have a very terse
statement in the descriptions of the packages.]

(not a maintainer of the existing httpcore and httpx packages) I didn't
even know these ones exist, I only knew about httpxyz.

But also neither httpx2 nor httpxyz provide `import httpx` (they expect
you to import them `as httpx`), so I wouldn't expect the Debian packages
provide that, so technically all of them can coexst, and

this, if done, would be against what the users expect.

See also:

https://httpxyz.org/httpx-compatibility/ (and what it does to sys.modules)

https://github.com/pydantic/httpx2/issues/963 (where the same is
requested)

Finally, I've found https://tildeweb.nl/~michiel/httpx2.html where the
author of httpxyz says "while we think httpxyz was definitely needed, we
welcome httpx2 and think it should be the ‘blessed’ fork" so I don't think
httpxyz should be considered.

I tried keeping both packages under the same source package, but
the upstream monorepo is not directly buildable in Debian as-is.

The workspace members rely on uv-dynamic-versioning for version
generation, which is not currently packaged in Debian. As a result,
building the monorepo requires either packaging uv-dynamic-versioning
first or carrying a Debian-specific patch to replace the dynamic
versioning with a static version.

On the other hand, the standalone httpcore2 source distribution already
includes the generated metadata required by hatchling and builds cleanly
with pybuild without any additional patches.

For that reason, I would prefer to keep httpcore2 as a separate source
package rather than carrying a versioning patch that would need to be
reviewed and updated for every upstream release.

Hello Matheus,

Am 15.06.26 um 04:11 schrieb Matheus Polkorny:

You package isn't the first package that fall into this limitation and
wont be the last. :-)

Patching out some uv/setuptools/PDM dynamic version tracking and
replacing isn't taking very much effort. I've done this in some of the
packages I did introduce into Debian in the past.
It's mostly adjusting the patch queue on version bumping or doing some
shell or Makefile magic in d/rules to work around in a more generic and
general way.

By my experience it's always the better way to not build another source
package and keep as much possible into one source package in case like
this package, the two build library are connected together very closely.

I can have a look at your preparations once I've take a deeper look
into. Mind to give me a link to your current WIP?