If that's the only purpose, why is there be an http server too? The package manager should only need an http client.

To host packages metadata?

My understanding is that it's there to allow for testing the client. Relevant issue: https://github.com/ziglang/zig/issues/910

is this true? i was excited that zig will provide a http server in its stdlib similar to what go does in fact.

Does a package manager not benefit from high-performance parallel HTTP (for downloading a bunch of little files)?

Sure. But I wouldn't do that for 1.0 of the lang. It sounds quite feasible to add support for that in 1.x if the community needs it. There's a reasonable path to upgrade to http/2 while spending more effort into what's critical for the lang to get to 1.0.

[Edit] And it's quite feasible to decide later that http/2 was never needed for this usecase.

Sure, but GP was saying "out of scope" in a way that sounded like "forever, for this use-case", not just "for 1.0". I may have misinterpreted

The package manager is designed to download archives (.tar.gz) of packages, not the composite files.

Most source code packages, including their metadata, are generally small even as an aggregated compressed file, and it's very common to download a lot of them all at one time once you've resolved the necessary dependencies. It depends on several factors though -- including community ones (are lots of tiny packages encouraged?) and how things like the build system work when downloading things.

In practice, it's very much an appropriate use case for multiplexing, if you ask me. But not having it isn't a dealbreaker either, IMO. It's a bit more work to support HTTP/2 and can be done rather transparently later on anyway, since the underlying transport can be switched and has an upgrade path.

> are lots of tiny packages encouraged?

Very much the opposite