Nixtamal: Fulfilling input pinning for Nix

Announcements
41

Definitely put a cookbook entry for it if that would be easy and/or fun!

1 Like
42

Good question what you want a cooldown relative to. One could argue for «the older commit of master 7 days ago and nixos-unstable now».

43

This does not guarantee that the choosen commit has been tested and verified by hydra. It might be a commit that is unbootable!

2 Likes
44

True, recently nixos-unstable has been about 7 days behind anyhow with Hydra builds.

45

I’ve recently tried this tool for finding out which nearest commit is in the public cache:
blitz/hydrasect: The tool that makes bisecting nixpkgs pleasant

46

Commits being “cached” is not the same as “commits being tested by hydra to ensure that neither the succesfully built kernel, boot loader, nor whatever important thing is faulty”.

47

Oh, I didn’t think of that. If we had Arbitrary reactions in Discourse I’d have reacted with :thinking: to that.

1 Like
48

Thanks @NobbZ I edited my comment to include a ‘disclaimer’.

Luckily I was not planning to use this anyway :smiley:

But I guess one would not have a hard time to fetch a build that works from Hydra, instead of Github with a similar solution.

To avoid derailing @toastal’s topic any further, I’ll leave it at that. The main takeaway seems to be: just let the input pinner do the input pinning.

1 Like
49

If anyone wants to know how to use multiple versions of Nixpkgs with Nixtamal: Using multiple version of Nixpkgs | Nixtamal

3 Likes
50

Nixtamal 1.8.0 released

  • NEW: Blueprints

    nixtamal set-up --blueprint BLUEPRINT, along with the basic setup, makes a default file structure + a demo package. Supported options are release & release-split for release.nix-style setups. A --blueprint release would make:

    ├── nix
│   ├── overlay
│   │   ├── default.nix
│   │   └── development.nix
│   ├── package
│   │   ├── demo.nix
│   │   └── dev-shell.nix
│   └── tamal
│       ├── default.nix
│       ├── lock.json
│       └── manifest.kdl
├── default.nix
├── release.nix
└── shell.nix

    where users can now have a basic working framework to build on as well as just being able to run nix-build release.nix -A demo

    I had gotten a lot of questions about how to set up / structure a classic Nix project, so now there’s a command you can build on.

  • Nixtamal subcommand manpages now shipped

  • lock/refresh now primes the silo if missing

4 Likes
51

I really like Nixtamal, thank you for working on it! One feature request I would like though - could the generated default.nix also optionally accept a nixpkgs instance for build-time fetchers? Currently the options are either to have at least 2 nixpkgs instances, or editing default.nix, both of which are not ideal. What do you think?

52

bootstrap-nixpkgs should do this as an attrset value to inputs = import ./nix/tamal { bootstrap-nixpkgs = <nixpkgs>; }. The only truly reproducible way is to use the pinned nixpkgs (hence the default), but in reality the pkgs.fetch* & their dependencies aren’t moving meaningfully often so I personally use the system’s stateful Nixpkgs frequently.

53

I’m not sure if we understood each other. I know about bootstrap-nixpkgs. My issue is, I want to avoid nixtamal doing import nixpkgs {} for me, as that creates a new nixpkgs instance, which means re-parsing all of nixpkgs, and re-evaluating the fetchers. Since I’ll be instantiating nixpkgs anyway, it’d be nice for me if I could just pass in pkgs directly to nixtamal, which in this case would be an existing instance of nixpkgs. I currently do this by editing the default.nix generated by nixtamal, but that’s not an ideal solution, as whenever I regenerate the lockfile, I need to patch the default.nix too.

54

Ah ha. Yes, I was actually just talking about that while walking thru the lock loader, default.nix, with a colleague this evening. Do you think the name bootstrap-pkgs is a good name?

2 Likes
55

I think so, yeah! Thanks for entertaining my comments

56

I should have a fix (5-ish lines) in the next repository. You can use import ${inputs.nixtamal}/nix/overlay to run the dev version if it helps. We’ll need a schema bump since the lock loader, nix/tamal/default.nix, needed changing & I try to keep the lockfile, lock loader, & manifest all in sync with 1 schema version. I’d cut a release for 1.10.0 but there are some other things I want to do.

1 Like
57

Nixtamal 1.10.0 released

Notable since I last posted a release here:

  • fetchPatch2 without experimental feature requirement & proper escaping
  • Rework how URIs are handled with new Locater newtype
  • fix Fossil tag collision
  • fix Pijul command handling
  • when upgrades are required, add a [Y/n] prompt which refires the command on upgrade
  • introduce bootstrap-pkgs for an already-instantiate Nixpkgs to use for bootstrapping
  • a couple blueprints improvements for what I consider the best non-flake project file structure setup
  • show error in the TUI
8 Likes
58

Nixtamal 2.0.0 released

  • Schema upgrade: 1.3.0 → 1.4.0
  • BUG: Refresh/lock with --patch does not refresh/lock all inputs
  • Lock loader refactored, now using Jingoo & a lot easier to maintain
  • Remote patches now allow more complexity like inputs; this includes frozen, name, & more importantly, their own fresh-cmd
  • extension support for Archive kinds give a hint to pkgs.fetchzip which can be added as a child to archive in the manifest.kdl
  • Zstandard support for pkgs.fetchzip by adding pkgs.zstd as a nativeBuildInput in the lock loader (base gnutar is missing support)
  • Nixpkgs Channels use Zstandard (.zst) over LZMA (.xz) which users will get when running nixtamal set-up --use-channels …
  • lock no longer refreshes patches naming isn’t clear enough to users
7 Likes
59

Nixtamal 2.1.0 released

  • BUG: lock loader syntax errors in the builtin Git fetcher block
  • Improve TUI & its related UX around fetching patches — including --skip-patches
  • Respect frozen inputs — specifically with regards to the new patch data (patch emailed by @Lord-Valen)
3 Likes