Nix For Lang Packaging: Difference between revisions
imported>Samueldr m Fixes most probably a pythonic mistake with ''' → '' / """ |
imported>Vater mNo edit summary |
||
| (5 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
{{Merge|Nix Expression Language|Article is essentially an introduction to the nix language}} | |||
= Overview = | = Overview = | ||
| Line 73: | Line 74: | ||
A lot of the time, a $lang2nix is provided to translate the dependency set into nix code. In general this becomes easier when a .lock file is provided because the $lang-specific dependency resolution has already been done. It is even easier if all the dependencies have an associated sha256 that matches how nix calculates them. | A lot of the time, a $lang2nix is provided to translate the dependency set into nix code. In general this becomes easier when a .lock file is provided because the $lang-specific dependency resolution has already been done. It is even easier if all the dependencies have an associated sha256 that matches how nix calculates them. | ||
== Curating a set of $lang dependencies == | |||
Some languages have been collected into lists of $lang packages within Nixpkgs. Each package is then pointed at the nixpkgs versions of its dependencies. (This is the Python preferred approach.) | |||
Pros: | |||
* Visibility | |||
* Fewer touchpoints in the face of updates (esp. for security) | |||
Cons: | |||
* More work on Nix-side for both library and application maintainers - the process is very manual. | |||
== Extending stdenv.mkDerivation == | == Extending stdenv.mkDerivation == | ||
| Line 92: | Line 104: | ||
Another difficulty is that because the `.git` folder is not guaranteed to have exactly the same content between clones (due to changes to the pack files), it makes it hard to always get the sha256. In most cases the `.git` folder can be removed to avoid these differences but it's not always possible. For example if the repo needs git submodules, or if the build system invokes `git` to find out repo metadata that get included in the build output, then the `.git` folder needs to be kept. | Another difficulty is that because the `.git` folder is not guaranteed to have exactly the same content between clones (due to changes to the pack files), it makes it hard to always get the sha256. In most cases the `.git` folder can be removed to avoid these differences but it's not always possible. For example if the repo needs git submodules, or if the build system invokes `git` to find out repo metadata that get included in the build output, then the `.git` folder needs to be kept. | ||
In the | In the GitHub case (and probably Bitbucket, GitLab, ...), the service also provides tarballs of specific hashes. Regularly the tarball output is also changed so nixpkgs resorts on hashing the unpacked content instead. | ||
All this means that there are many possible variations and it's going to be hard to agree on which-one is the best. | All this means that there are many possible variations and it's going to be hard to agree on which-one is the best. | ||
| Line 103: | Line 115: | ||
* The $lang build tool could expose it's build plan to help interspersing nix | * The $lang build tool could expose it's build plan to help interspersing nix | ||
* ... | * ... | ||
[[Category:Tutorial]] | |||
[[Category:Development]] | |||
[[Category:Nixpkgs]] | |||