@Mathnerd314 Great work!

I think this would be better to solve in nixpkgs as we do for other package sets. I would assume there would be texlivePackages which we would have to traverse into.

nixos search is already a lot of hacks and a small force is keeping it all together for now. I would hate to add more complexity to it, especially since it would be better to upstream this. What do you think, can you open a PR against nixpkgs and reference this discussion?

I tried hacking on it, but the texlive code is quite complicated compared to other package sets with the way it filters and groups outputs. I don't think I can open a PR. Maybe @veprbl knows the code better than me...

@Mathnerd314 So expression in the PR doesn't work yet?

Well, it works as far as I can test it (for basic packages, not for collections or schemes). But AIUI @garbas is saying he'd rather change nixpkgs than include a workaround in nixos-search. But from poking around, it seems changing paths like texlive.memoir to be stdenv derivations rather than lists would require rewriting a lot of the package filtering logic.

@Mathnerd314 We could move your expression to texlive.__search, but we would still need to somehow do the s/texlive.__search./texlive./ on the path. In any case, I doubt we are going to be able to make texlive.memoir into a real installable package, AFAIK this is not how texlive can work.

@veprbl I'm not aware how texlive packaging is done, but search.nixos.org will only list installable packages. I assume the situation is similar as with vimPlugins for example or emacsPackages. You can not really use it if you install it but it is still a derivation.

@garbas

search.nixos.org will only list installable packages

Sorry, I'm confused. It currently does search on emacsPackages, but those are not installable.

@veprbl

search.nixos.org will only list installable packages

Sorry, I'm confused. It currently does search on emacsPackages, but those are not installable.

Sorry for the confusion. I think I to define what installable package is and then discussion will be easier 👍

An installable package is a derivation and has a clear attr path to it.

In case of emacsPackages you can do nix-env -iA nixos.emacsPackages.jeison or nix build nixpkgs#emacsPackages.jeison or nix-build ./path/to/nixpkgs -A emacsPackages.jeison.

In case of texlive I would expect there would be a texlivePackages (or texlive.packages or something similar) to follow a common pattern in nixpkgs. Then one could do nix build nixpkgs#texlivePackages.12many to install a texlive package, like you can do with emacsPackages, pythonPackages, vimPlugins, etc ... I think currently you need to do something like nix build nixpkgs#textlivePackages.12many.0 (where 0 pointing to the first element in the list).

Would it be possible to create texlivePackages?

I guess we could talk about different levels of "installable packages":

0. Addressable by an attribute path. Unfortunately there isn't much support in Nix tooling for addressing lists. There is also not much reason for the texlive "packages" to be presented by ordered lists, so they might as well have been attrsets with keys like run, doc, source, or even a single derivation with multiple outputs. This is, however, not the current design and changing it would break the backwards compatibility.
1. Derivations actually working when installed. This might require some modifications to the kpathsea configuration and/or some other patching to make this work.
2. Derivations pluggable via shellHook. This could require similar framework as for 1. perhaps with some different performance trade-offs.

I'm only sure that 0. is achievable, but personally I am not convinced that it is worth it on its own.

@veprbl yes, number 0 is what is needed. maybe if this new API is created as texlivePackages and also preserving existing way of having an ordered list. A single derivation with multiple outputs sounds like it would the right way (the most nix way) to do it.