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.
I am certain the following is going to be very much a niche opinion, but I’ll give it anyway. There are two primary reasons I dislike the package management (and yes, this applies to Rust, Zig, Python, Go, basically everything JavaScript, etc) system both in theory and practice.
First, I am of the opinion that any centralized package management inevitably leads to heavy reliance on those packages. The comments of ‘there is a crate for that’ or ‘just look on NPM’ or ‘it’s on PIP’ are often the first answers anyone gives to people looking to write code to do a certain thing. That leads to towers of imports and dependencies. I am fundamentally opposed to not writing the simplest and most specific code for any given problem. Package management is a type of institutional environment directly opposed to that fundamental opinion. I am not interested in generic, allegedly re-usable, solutions, I want the most simplistic/direct solution/implementation I can code. Now sometimes that solution is a library and sometimes that library is complex, but that is a decision that is made purposefully and with the knowledge that the dependency MUST be managed as though the code was written by you. I think the package management paradigm being used/targeted by most modern languages assume that by using a dependency means I am outsourcing a potion of my code to others and that I am willing and able to change my code according to what changes with the dependency. I tend to only use direct source dependencies that I can make completely local and that code just becomes part of my program, and yes that means there are no updates to that code I do not make myself. An update of the dependency itself will only be included after reviewing the update as though it were a new dependency, i.e. purposefully and by me, not whenever the vendor wants and not whatever the vendor chooses.
I am aware that there is no requirement to use package management to incur what I find are negatives, but I truly believe that the environment and common usage patterns push development practice towards the type of coding practices I dislike.
Second, for work purposes, I can not use any code I can not warranty as fit for purpose and conforming to terms of a given contract. This means that any code which has a ‘no warranty’ statement in the license (which is almost all library code in every language regardless of distribution mechanism) I can only use once I have reviewed enough of it and am confident enough in it that I can put specific functional guarantees in place regarding specific performance of contract terms. Package management systems, and their accompanying practices, are not particularly appealing when the package management strategy seeks to continually push updates and continually seeks to stack reliance on large dependency trees. I am often better off designing and programming something myself that attempting to review to an acceptable degree a tangled mess of dependency.
I find that, while often an explicit non-goal for most programming languages, I would best be served by explicitly bare source code libraries, which are stored and compiled locally, and are incorporated into a project purposefully and in the same manner as files authored by me. Again, I am aware my requirements are not industry standard and my opinions are not mainstream, but there ya go.
With you on package management issues. The thing is modern devs just use a package for the simplest things just to feature load the code. Often you don't need all the functionality of the dependency. You'll probably use 0.1% of it. But javascript and rust repos dependency tree is extremely deep on average.
This in fact _hurts_ maintainability as you need to manage this heavy, recursive dependency tree. Ultimately it's not hackable. You can't just change that function to print a warning, rather you have to edit an entire library and work through it's taxonomy.
I'd note that Python is much better than others you list at this. Idiomatic python tends to be "batteries included" and shouldn't use too many dependencies other than those that are crucial to the project (ex Numpy). It's probably also because Python's package management story isn't as polished as others.
In the elixir ecosystem, we have private package management (plus software BOM support), which probably would be useful to you as it would let you share code internally for your own team. As long as zig's PM system gives you the flexibility to repoint the package manager to your own domain, you'd probably find the availability of some package manager better than bare code management, if for no other reason than it will make it easier to have internal consistency with component versions and dependencies.
That's an argument against having any package management at all. I respect that, but I don't really think it's viable in open source communities -- even Perl had CPAN decades ago.
You want the rural living version of programming languages. Package management is a dense urban core.
