| 10 Dec 2024 |
 Sandro 🐧 | 👉️👈️ Can I motivate someone to fix https://github.com/NixOS/nix/issues/8074 ? 🥺 | 15:25:14 |
| 11 Dec 2024 |
|  cy changed their profile picture. | 05:09:28 |
|  kat ⛧ they/them joined the room. | 12:05:42 |
|  marijan changed their profile picture. | 14:20:17 |
 p14 | I'm having an issue that in my org, the simple invocation nix build nixpkgs#hello fails. The github API requests fail unless authenticated, since there are a large number of users going through the same IP address. Of course the 'obvious' solution is to get everyone to authenticate, but this creates problems on remote machines of where to store the token.
I'd like instead to point flake:nixpkgs at an internal mirror (via nix registry pin or equivalent), but AFAICT there is no efficient way to do this? The reason it's efficient for github is the existence of the download API which is special cased to github. Is there a way to achieve the same effect?
I've tried for example to point it at a local git repository, but this results in nix trying to clone the nixpkgs git repository, which is incredibly expensive in time, CPU time, disk and bandwidth.
How do others handle this, or does everyone simply supply a github token? I'm just not sure this is a scalable approach, and it would be nice to drop the requirement of github being visible to the machine invoking nix.
| 14:56:05 |
| Sandro 🐧 | http_proxy envs and the like? | 14:57:34 |
| Sandro 🐧 | or just copy the downloaded store entry to the machine | 14:57:48 |
| Sandro 🐧 | the one place where this happens to me, I just have tokens | 14:58:02 |
| p14 | I'm not clear how a http proxy helps matters? Wouldn't that again have the effect of concentrating requests to go through one IP and requiring that they're authenticated? Since it uses https I don't see how the proxy could even provide the authentication if I was inclined to go that route. | 14:59:36 |
| p14 | Having a store on the machine could work, but I need to persuade nix not to query the github API at all. | 14:59:55 |
| p14 | (a store = a copy of a nixpkgs tree) | 15:00:08 |
| p14 | But there is still the secondary problem of user flakes: those will contain references to nixpkgs, and those references also need to be acquired. This also generates a similar problem that needs solving | 15:00:44 |
| Sandro 🐧 | I personally follow nixpkgs on every flake input | 15:01:45 |
| p14 | I suppose in this latter case, at if the user has a locked flake, it's possible (maybe?) to substitute the nixpkgs tree from a substituter, which would be acceptable. But that's only fine so long as they have a locked flake and breaks if they want to nix flake update. | 15:01:49 |
| p14 | Right, but nixpkgs will still be locked into the flake as github:nixos/nixpkgs, no? | 15:02:02 |
| Sandro 🐧 | yeah, basically | 15:02:12 |
| p14 | Really I need some way of telling nix 'these things are available from this other place'; and for nix to query for example what the latest commit is from that place, and not github. | 15:03:30 |
| p14 | The problem is that many obvious places to put a git repository don't provide an efficient way to acquire a checkout tree of nixpkgs at a specific commit. | 15:04:18 |
| p14 | (e.g, I don't think gerrit provides an equivalent of github's /archive/) | 15:04:32 |
 Alyssa Ross | Gerrit is usually paired with gitiles, which dose. | 15:05:59 |
| p14 | Right but can nix fetch a tree through it? | 15:06:17 |
| Alyssa Ross | * | 15:06:19 |
| p14 | (and better, can I redirect requests to github to a gitiles instance?) | 15:06:38 |
| Alyssa Ross | I don't think so, although it could — we have a gitiles fetcher in Nixpkgs. | 15:06:42 |
| p14 | Right, fetching via gitiles could work. But I don't see a fetcher in nix? (No grep hits, no PR hits). And even if there was, there would also need to be a redirection mechanism in nix | 15:12:28 |
| p14 | So, I think I have a sort-of route. 1) we’d need a gitiles fetcher. 2) the machines which can’t access github can have a registry pin for nixpkgs which points them to the private gitiles mirror. Minor detail that a gitiles would be needed.
And the other minor detail that any flake lockfiles made on those machines would end up referencing the mirror, and not the original github repository as you would probably want. | 17:30:43 |
| p14 | An additional annoyance is that the mirror actually has different URLs in different contexts. So you’d really not want to write those into lockfiles if possible. | 17:33:57 |
| 12 Dec 2024 |
|  query.roads joined the room. | 19:44:36 |
| 13 Dec 2024 |
|  @alethkit:matrix.org left the room. | 10:34:07 |
| 14 Dec 2024 |
|  sinan changed their profile picture. | 03:00:24 |
