Thanks. I didn’t know that worked, however I’d say this is rather advanced nix.
Sorry, I assumed you were an advanced user/the code was easier to understand. It’s easy to get caught up in the imposter syndrome.
I know genAttrs “generate[s] an attribute set by mapping a function over a list of attribute names”, however for this piece of code I’d have trouble locating the list of attribute names.
You mean packageNamesToModify? You have to provide those. I don’t know which packages could be built with my-proprietary-codec and it’s not feasible to figure that out automatically.
But I guess this is because I don’t understand overrideAttrs fully / correctly. In my defense, locating the documentation for that one isn’t trivial – I think this requires having some more experience with the language and the needed libraries.
Yes, certainly. overrideAttrs allows you to “modify” the argument originally passed to mkDerivation such as src, pname, version, buildInputs and many more. To understand overrideAttrs, you must know what these common mkDerivation arguments mean. From then on, overrideAttrs is trivial to understand.
It’s like writing a derivation but “updating” an existing derivation to be slightly different.
While I know that genAttrs is defined and explained in nixpkgs/lib/attrsets.nix, I’m not so sure about overrideAttrs– I’d guess it’s in nixpkgs/pkgs/stdenv/generic/make-derivation.nix? Even ryantm.github.io/nixpkgs/using/overrides/#sec-pkg… is not very verbose.
Please don’t take this as criticism, I know nix is a full language and I’m not trying to bash anyone here, however there’s quite the learning curve.
Oh absolutely. There’s quite the learning curve, almost everyone knows that. It’s just not an easy thing to fix and you don’t tend to think about learning things you already know, so it’s not constantly in people’s minds.
What you’re actually looking for here is a Gentoo USE-flags like system. We have a precursor of that in i.e. config.cudaSupport but it’s not widely used.
In my uneducated opinion, full use of USE-flags are rather complicated with package managers providing binaries, no? It would require a big number of builds for all possible options and their combinations.
I’ma let you in on a little secret: We’re not actually a binary distribution. We’re source-based.
It’s integral to the functional approach. Every artefact is a more-or-less direct result of a realisation which is the direct result of an evaluation of Nix expressions. The latter is pure and the former we strive to make as pure as possible via sandboxing.
This allows us to treat artefacts as replaceable objects which means that instead of building locally, we can substitute the (theoretically) same artefact from somewhere else and that’s the binary cache.
You’d do that upstream because that’s something that every instance of ffmpeg should be able to do. And also ping me because I maintain ffmpeg ;)
Thanks for your work, I don’t really need jpeg-xl in ffmpeg, I played around with it when I was still using Arch (i.e. take screenshots in the format in mpv) but it wasn’t urgent enough for me to file an issue on Github.
If you’re at all interested, go ahead and do so. That’d make for a great first PR. JXL support is something you’d expect of ffmpeg in the near future (if not already), so this will happen anyways.