36 Matching Annotations
  1. Feb 2021
    1. the single repository technique. The natural implementation in Nix is to create a top-level Nix expression, and one expression for each package. The top-level expression imports and combines all expressions in a giant attribute set with name -> package pairs. But isn't that heavy? It isn't, because Nix is a lazy language, it evaluates only what's needed! And that's why nixpkgs is able to maintain such a big software repository in a giant attribute set.

      This is the gist of how Nixpkgs works (and how it is organized).

    2. 17.3. Fixed point

      QUESTION: What is a fixed-point of a function?

      ANSWER: See this video) at least, and the Fixed-point (mathematics)) wikipedia article:

      In mathematics, a fixed point (sometimes shortened to fixpoint, also known as an invariant point) of a function is an element of the function's domain that is mapped to itself by the function. That is to say, c is a fixed point of the function f if f(c) = c. This means

      f(f(...f(c)...)) = f n(c) = c

      an important terminating consideration when recursively computing f. A set of fixed points is sometimes called a fixed set.

      For example, if f is defined on the real numbers by f(x)=x^{2}-3x+4,}, then 2 is a fixed point of f, because f(2) = 2.

      There is also the wiki article fixed-point combinator that actually plays a role here, but read through the articles in this order.

      Then dissect the Stackoverflow thread What is a Y combinator?, and pay attention to the comments! For example:

      According to Mike Vanier's description, your definition for Y is actually not a combinator because it's recursive. Under "Eliminating (most) explicit recursion (lazy version)" he has the lazy scheme equivalent of your C# code but explains in point 2: "It is not a combinator, because the Y in the body of the definition is a free variable which is only bound once the definition is complete..." I think the cool thing about Y-combinators is that they produce recursion by evaluating the fixed-point of a function. In this way, they don't need explicit recursion. – GrantJ Jul 18 '11 at 0:02


      Other resources in no particular order:

      QUESTION: How the hell did they come up with the idea of using this with Nix and package management? (..and who? I remember a video saved somewhere, but maybe that was about overlays)

      QUESTION: ... and how does it work in this context?

      ANSWER: Well, not an answer yet, but this may be something in the right direction:


    1. $stdenv/setup

      QUESTION: Does this refer to pkgs/stdenv/generic/setup.sh? According to 6.5 Phases in the Nixpkgs manual?

      ANSWER: I'm pretty sure it does. It sets up the environment (not sure how yet; I see the env vars, but not the basic commands - sed, awk, etc. - that are listed below) and defines a bunch of functions (such as genericBuilder) but it doesn't call these functions!

    1. Specifying a name and a src is the absolute minimum Nix requires.

      Didn't they mean what mkDerivation requires?

      I have been jumping around in this manual, so not sure about what arguments does derivation require.

    2. For convenience, you can also use pname and version attributes and mkDerivation will automatically set name to "${pname}-${version}" by default.

      The error messages are not helpful when one messes up the input attribute set ofmkDerivation (i.e., either name, or pname and version attributes have to be present); see Nixpkgs issue #113520.

    3. 6.1. Using stdenv
    4. fetchpatch works very similarly to fetchurl with the same arguments expected. It expects patch files as a source and and performs normalization on them before computing the checksum. For example it will remove comments or other unstable parts that are sometimes added by version control systems and can change over time.
    5. 19.3. Submitting security fixes Security fixes are submitted in the same way as other changes and thus the same guidelines apply. If the security fix comes in the form of a patch and a CVE is available, then the name of the patch should be the CVE identifier, so e.g. CVE-2019-13636.patch in the case of a patch that is included in the Nixpkgs tree. If a patch is fetched the name needs to be set as well, e.g.: (fetchpatch { name = "CVE-2019-11068.patch"; url = "https://gitlab.gnome.org/GNOME/libxslt/commit/e03553605b45c88f0b4b2980adfbbb8f6fca2fd6.patch"; sha256 = "0pkpb4837km15zgg6h57bncp66d5lwrlvkr73h0lanywq7zrwhj8"; }) If a security fix applies to both master and a stable release then, similar to regular changes, they are preferably delivered via master first and cherry-picked to the release branch. Critical security fixes may by-pass the staging branches and be delivered directly to release branches such as master and release-*.
    6. 18.6. Patches Patches available online should be retrieved using fetchpatch. patches = [ (fetchpatch { name = "fix-check-for-using-shared-freetype-lib.patch"; url = "http://git.ghostscript.com/?p=ghostpdl.git;a=patch;h=8f5d285"; sha256 = "1f0k043rng7f0rfl9hhb89qzvvksqmkrikmm38p61yfx51l325xr"; }) ];

      ... and from Chapter 11:

      fetchpatch works very similarly to fetchurl with the same arguments expected. It expects patch files as a source and and performs normalization on them before computing the checksum. For example it will remove comments or other unstable parts that are sometimes added by version control systems and can change over time.

      ... and also adding highlight of 19.3. Submitting security fixes

      because these are the only places I've seen fetchpatch mentioned.

      From the wild in freeswitch/default.nix in Nixpkgs:

      stdenv.mkDerivation rec {
        pname = "freeswitch";
        version = "1.10.5";
        src = fetchFromGitHub {
          owner = "signalwire";
          repo = pname;
          rev = "v${version}";
          sha256 = "18dhyb19k28dcm1i8mhqvvgm2phsrmrwyjmfn79glk8pdlalvcha";
        patches = [
          # https://github.com/signalwire/freeswitch/pull/812 fix mod_spandsp, mod_gsmopen build, drop when updating from 1.10.5
          (fetchpatch {
            url = "https://github.com/signalwire/freeswitch/commit/51fba83ed3ed2d9753d8e6b13e13001aca50b493.patch";
            sha256 = "0h2bmifsyyasxjka3pczbmqym1chvz91fmb589njrdbwpkjyvqh3";
        postPatch = ''
          patchShebangs     libs/libvpx/build/make/rtcd.pl
          substituteInPlace libs/libvpx/build/make/configure.sh \
            --replace AS=\''${AS} AS=yasm
          # Disable advertisement banners
          for f in src/include/cc.h libs/esl/src/include/cc.h; do
              echo 'const char *cc = "";'
              echo 'const char *cc_s = "";'
            } > $f
    7. 6.5. Phases

      Not sure why this isn't called build phases... See also.

    1. example: get an environment which is used to build irssi (also see nix-shell) $ nix-build $NIXPKGS --run-env -A irssi example: get a persistent environment which is used to build irssi $ nix-build $NIXPKGS --run-env -A irssi --add-root

      nix-build <path> --run-env has been superseded by nix-shell. From Nix manual section C.12. Release 1.6 (2013-09-10):

      The command nix-build --run-env has been renamed to nix-shell.

    2. git clone --depth=1 https://github.com/nixos/nixpkgs

      i should remember this to only get last commit, which basically means to only care about the data, and discard commit history.

  2. Sep 2020
  3. Aug 2020
    1. builtins.attrValues set

      TODO: Is this the same as lib.attrsets.attrValues in nixpkgs?

    1. lib.attrsets.attrValuesattrValues :: AttrSet -> [Any]

      TODO Is this an alias to builtins.attrValues?

    2. TODO: document lib.mkIf

      Found a description in the NixOS manual:

      The special function mkIf causes the evaluation of the conditional to be “pushed down” into the individual definitions, as if you had written:

      config = {
        environment.systemPackages = if
      config.services.httpd.enable then [ ... ] else [];
    3. TODO: document lib.mkDefault

      Not mentioned in any of the manuals (i.e., nix, nixpkgs, NixOS), only the NixOS options page has 1 mention:

      Some promising search result (in the order of relevance):

      From source:

        mkOverride = priority: content:
          { _type = "override";
            inherit priority content;
        mkDefault = mkOverride 1000; # used in config sections of non-user modules to set a default

      It seems that all the mkOverride calls set up a priority for certain actions.

    4. 5.1.7. NixOS / nixpkgs option handling

      What is an option?

      From the link below to the source, it's just an attribute set with all the function parameters (see below) plus a _type attribute name to allow for type level operations (because Nix is untyped).

        mkOption =
          # Default value used when no definition is given in the configuration.
          default ? null,
          # Textual representation of the default, for the manual.
          defaultText ? null,
          # Example value used in the manual.
          example ? null,
          # String describing the option.
          description ? null,
          # Related packages used in the manual (see `genRelatedPackages` in ../nixos/lib/make-options-doc/default.nix).
          relatedPackages ? null,
          # Option type, providing type-checking and value merging.
          type ? null,
          # Function that converts the option value to something else.
          apply ? null,
          # Whether the option is for NixOS developers only.
          internal ? null,
          # Whether the option shows up in the manual.
          visible ? null,
          # Whether the option can be set only once
          readOnly ? null,
          # Deprecated, used by types.optionSet.
          options ? null
          } @ attrs:
          attrs // { _type = "option"; };

      How does it fit in a big scheme of things?


    5. lib.attrsets.recursiveUpdateUntil

      If there is recursiveUpdateUntil (i.e., mergeUntil) then mergeWith would also be welcome.

    6. lib.attrsets.recursiveUpdaterecursiveUpdate :: AttrSet -> AttrSet -> AttrSet

      Would be nice to have an alias called merge.

    7. String -> Any -> { name = String; value = Any }

      Fix: add semicolon after last Any. (same above in the main type signature)

    8. mapAttrsToList :: (String -> Any -> Any) -> AttrSet -> Any Located at lib/attrsets.nix:233 in <nixpkgs>. Call fn for each attribute in the given set and return the result in a list.

      So the type signature

      (String -> Any -> Any) -> AttrSet -> Any

      should be

      (String -> Any -> Any) -> AttrSet -> List

      instead, right?

    9. lib.attrsets.collectcollect :: (Any -> Bool) -> AttrSet -> [Any]
    10. lib.attrsets.catAttrscatAttrs :: String -> [AttrSet] -> [Any] Located at lib/attrsets.nix:113 in <nixpkgs>. Collect each attribute named `attr' from the list of attribute sets, sets.

      Then why not call it collectVals?... (Following the distinctive naming convention between lib.attrsets.attrVals and lib.attrsets.attrValues.)

      Especially because there is lib.attrsets.collect:

      catAttrs :: String -> [AttrSet] -> [Any]
      collect :: (Any -> Bool) -> AttrSet -> [Any]

      (Call it filterVals? There are filterAttrs* functions but those return an attribute set, so no collision.)

    11. Attribute-Set

      This should read "Attribute Set Functions". Nowhere else is attribute sets spelled as "attribute-set".

      edit: Alright, "attribute-set" is used in total of 4 times, whereas "attribute set" is used 112 times.

  4. Jun 2020
    1. Basic Install environment.systemPackages = with pkgs; [ vim ]; or environment.systemPackages = with pkgs; [ vim_configurable ];

      What is the difference between the vim and vim_configurable packages?

      I believe the source for the latter is here.

  5. Nov 2019
  6. Feb 2019
  7. Oct 2018
  8. Jul 2018