Sometimes it helps to append a version number to the end of the package name. For example: Go has a convention of go_major_minor in nixpkgs that you can use to find specific versions, so go_1_21 will get you the version you want. This convention is a little different for different packages (e.g., Python uses pythonMajorMinor, like python39)
Another option is to search for the package on tools like Nixhub, which aggregates all the current and historic versions for a package on one page. Hereās the page for Go: go | How to install with Nix or Devbox
Iāve never heard of nixhub, I donāt think itās an official resource. I think the source of truth for available packages in nixpkgs is NixOS Search. It looks like bazel 6.3.2 is in there.
Since you mentioned the registry, I assume youāre using flakes as opposed to channels. Can you post the output of nix flake metadata nixpkgs and nix flake run nixpkgs#bazel -- --version?
Ah, you were using āregistryā in a different sense.
Iām not sure about channels, but you can have packages from different revisions of nixpkgs, which channels are a layer of abstraction over. Check out this link for an introduction to using specific git revisions of nixpkgs in your shell.nix, as opposed to <nixpkgs>, which will be determined by your channels: https://nix.dev/tutorials/first-steps/declarative-and-reproducible-developer-environments
Then you can extend this and bring in multiple versions of nixpkgs by git hash using fetchTarball.
The alternative way is to use a flake. Flakes are nominally an experimental feature, but widely used in practice and unlikely to change significantly. Using a flake for this task would look like this:
We can enter the devShell with nix develop (although this wonāt work for you out of the box without enabling flakes). We donāt have to specify a specific git revision for nixpkgs-unstable to make this reproducible, even though itās a moving target. This is because nix will create a lockfile pinning the current version as soon as we build.
I prefer this method, even though thereās more boilerplate involved, because you get a similar UX to other programming language package managers with lockfiles. The pinning is done for you so you donāt need to think about git revisions if you donāt want to, and there are commands for updating your inputs. I recommend this article for a comprehensive introduction to flakes.