| 2 Apr 2025 |
 John Ericson | especially because, as ElvishJerricco mentioned, actually the mkMesonPackage stuff and whatnot really ought to not be Nix-specific, but reused for other things like (potentially) systemd | 20:35:32 |
 emily | SGTM, especially if we can get a componentized-compatible overrides interface for patching/build flags/env.NIX_CFLAGS_COMPILE on the monolithic one | 20:40:43 |
| emily | sorry, I definitely do not have the time and do not feel I understand the packaging well enough to :( | 20:41:03 |
| John Ericson | I guessed I mixed up my metaphors here, what about just on the monolithic package? | 20:42:03 |
| John Ericson | (poly package maintenance for systemd is an orthogonal question) | 20:43:04 |
| emily | is the idea to keep the monolithic package around? I assumed that we'd want to switch to the componentized one early in 25.11 to shake out any issues well ahead of release | 20:56:43 |
| John Ericson | emily: yes, yeah the idea is to get rid it early in the cycle | 20:59:57 |
| John Ericson | so we are not in this some position come november | 21:00:02 |
 fzakaria | I asked this on twitter but maybe here is a better place.
On my MacOS Nix installation (2.26) I'm surprised in my flake project how often I hit:
unpacking 'github:NixOS/nixpkgs/b7ba7f9f45c5cd0d8625e9e217c28f8eb6a19a76' into the Git cache.
| 22:55:51 |
| fzakaria | Is this a bug in Nix or something I'm missing. | 22:56:04 |
| 3 Apr 2025 |
| John Ericson | * so we are not in this same position come november | 03:12:00 |
|  mjolnir banned  @cafkafk:fem.gg (<no reason supplied>). | 11:41:55 |
 Mic92 | fzakaria: what do you mean by often? is this for the same commit? | 12:16:39 |
| Mic92 | I can also recommend: nixpkgs.url = "git+https://github.com/Mic92/nixpkgs?shallow=1&ref=main"; | 12:17:10 |
|  @2xsaiko:tchncs.de changed their display name from 2xsaiko to 2xsaiko (moved! @saiko:knifepoint.net). | 12:52:04 |
 teto | does the shallow do anything ? I would suspect it's the default | 17:50:38 |
| emily | GitHub really doesn't like people doing shallow clones of the same repo repeatedly, fwiw. (they've had other package managers change their update mechanism because of that in the past) | 19:22:16 |
 jade_ | i would never recommend this over a tarball input. if it's a nix bug, nix should fix it. | 20:44:34 |
| jade_ | * i would never recommend this over a tarball input. if it's a nix bug, nix should fix it. git clone is very slow and resource intensive compared to a tarball fetch such as the github: flake URL scheme. | 20:45:00 |
| 4 Apr 2025 |
|  redrield joined the room. | 00:17:02 |
| mjolnir unbanned @cafkafk:fem.gg. | 06:12:58 |
| Mic92 | Shallow clones are significantly faster for me than downloading tarballs and it's not slower than downloading tarballs for an initial clone. | 10:56:02 |
| Mic92 | * Shallow clones when updating are significantly faster for me than downloading tarballs and it's not slower than downloading tarballs for an initial clone. | 10:56:14 |
| Mic92 | No it's not the default because git inputs have a revcount flag that cannot be computed when doing a shallow clone. | 10:58:58 |
| teto | do you know a reference talking about this : is it a CPU vs bandwidth tradeoff (shallow clones being more CPU intensive) ? | 11:01:14 |
| teto | is revcount that useful ? I never used that I think | 11:01:38 |
| Mic92 | Github uses them in their official checkout action ... | 11:01:49 |
| Mic92 | Agreed but removing it would change evaluation of existing flake.locks | 11:02:31 |
| emily | I think it was CocoaPods or Homebrew or both | 11:19:42 |
| emily | I believe serving shallow clones is expensive, I guess because it is the CPU cost of the Git protocol without the network savings? | 11:19:59 |
