What is important is that nix does not implement version range resolution.
In nix expressions you have to depend on one specific package that packages one specific version, hence the
Many language package managers implement version resolution for in varying complexity, but most importantly in a different way, that makes it hard or at least inconvenient to implement the same in nix.
Now, you see that for your package there is no single nixpkgs yet that contains a valid combination of its dependencies.
Luckily nix allows you to provide your own versions (and can pull versions directly from hackage)
You can take registry/default.nix at floxify · ysndr/registry · GitHub for reference on how to do that.
However, what i would be very interested in is getting to know your goal with packaging your library.
- would you like to create an environment to develop that library]
- will that require nix provided dependencies?
- or do you just need the cabal/hls/ghc/… environment to be able to work on it?
- would you like to provide the lib to other binaries of yours as dependency and want it to be a newer version than the one shipping with nix?
Nix packages defines a large subset (all?) of the latest hackage releases
That is because the haskell community bought into nix quite early - stack has official nix support.
Hackage has 15644(today) packages, which are all somewhat referenced in nixpkgs (e.g, https://raw.githubusercontent.com/NixOS/nixpkgs/master/pkgs/development/haskell-modules/hackage-packages.nix) – that includes registry (3.2.1)
Why does flox search not find these?:
In short, for performance reasons.
flox search needs to evaluate all these 15k packages in order to show them.
The same is true for
pythonPackages (less complete than haskell but still, big!) and a couple of other package sets which had to be included as well
Also flox build is still more targeted to package consumers showing what you can install to your environments rather than use in your build expressions.
Why does search.nixos.org find these packages?:
search.nixos.org indexes a greater extend of nixpkgs and stores it on an elasticsearch instance.
Searching on the website is therefore more efficient as its served by an actual search engine.
We have solutions in mind for similar approaches in flox but were not there just yet.
Why so many tasty hedgehogs?
Nixpkgs has not figured out how to encode multiple versions of the same package.
A nix expression packages one specific version of a program.
If two versions are packaged they cannot share the same name, but have to be distinguished somehow, often by the package name.
On top of that the
haskellPackages are generated automatically and more versions might be added manually to agree with package constraints