I believe indexing package ecosystems is quite important in order to better integrate foreign ecosystems with nix.
I have done some indexing projects in the past like pypi-deps-db or nix-pypi-fetcher which are the basis for approaches like mach-nix
Also the haskell infrastructure in nixpkgs depends on indexes like all-cabal-hashes.
Having a more uniform way for indexing, storing, and accessing this kind of data would be of great use, I believe.
There is already https://libraries.io, but the data there is not suitable for reproducible builds as it doesn’t contain checksums for sources etc. and it doesn’t have a great way of exporting subsets of the data, AFAIK.
Another problem is, that as of now, nix itself cannot really be used for dynamic dependency management. Currently all language2nix approaches rely on external tools to resolve dependencies and generate lock files.
For example, one can build a nodejs project with buildNpmPackage or dream2nix, but in order to add dependencies or update them, one still needs to call out to npm.
In many environments nix is only suitable as an addition to other package managers, not as a replacement.
If we want to have a more nix-native approach to dependency management itself, we need reproducible metadata access for more external ecosystems.
Having that, would allow us, for example, to implement reproducible dependency resolution across ecosystems without calling out to many different tools.
The indexes mentioned above, are non-standard, ad-hoc solutions for specific ecosystems.
Projects with the goal of unifying these indexing approaches sound like they could align well with
NGI Search and could be of great use for the nix ecosystem and potentially other ecosystems.