On the off-chance that you're asking because you're involved in the package manager, here are a few things I'd really like to see as a crusty graybeard / softwa

On the off-chance that you're asking because you're involved in the package manager, here are a few things I'd really like to see as a crusty graybeard / software carpenter / package maintainer. Maybe some/all of these are already true for Zig's package manager. 1. Don't assume that packages come from Github. Or from any specific URL, for that matter. Or that they're managed in Git. Make it controllable with a config file, and ship a default config file. Let a project-specific config file override a site-wide one. 2. Make sure packages can come from multiple sources. 3. Make it possible to use packages from the local filesystem. Support relative paths. 4. Don't try to do network access unless I specifically ask for a fetch/download/update/etc. I want to be able to extract a few source tarballs somewhere, and then run a build that doesn't require me to be online. 5. Have a good story for working with non-Zig libraries. Like if I want to make a FUSE filesystem or something, it probably depends on having libfuse and libfuse-dev installed from my distro package manager. Zig's package manager doesn't need to interact with apt-get or whatever, but it would be great if it knew how to find local headers and libraries. 6. Include a way for me to generate a source-tarball that bundles the sources for all of my program's dependencies, so that I can archive it and reproduce a build later even if the upstream sources go away. 7. Include a license tracking/reporting mechanism, so that I know the licenses of all software I've pulled in as a dependency (whether directly or indirectly). I don't want a situation where I have some dependency that has another dependency on another dependency, and 3 levels down there's something that's got a license I can't ship. The Yocto project did this in a very smart way, and it's a good model to copy. 8. Have a way to express build-time dependencies and run-time dependencies. Those aren't necessarily the same thing, and might not even target the same platform.