Skip to content

import callLocklessFlake#69

Closed
zimbatm wants to merge 1 commit into
masterfrom
call-lockless-flake
Closed

import callLocklessFlake#69
zimbatm wants to merge 1 commit into
masterfrom
call-lockless-flake

Conversation

@zimbatm

@zimbatm zimbatm commented May 26, 2022

Copy link
Copy Markdown
Member

This function was added to nixpkgs in
NixOS/nixpkgs#167947 by @MatthewCroughan.
And later reverted because it's for unstable flakes.

So let's add it here, since a lot of projects are already importing
flake-utils.

This function was added to nixpkgs in
NixOS/nixpkgs#167947 by MatthewCroughan.
And later reverted because it's for unstable flakes.

So let's add it here, since a lot of projects are already importing
flake-utils.
@zimbatm zimbatm force-pushed the call-lockless-flake branch from 7d5ff83 to 9046d46 Compare May 26, 2022 08:18
@MatthewCroughan

Copy link
Copy Markdown

😿 now I need to have a dependency on flake-utils.

@zimbatm

zimbatm commented May 26, 2022

Copy link
Copy Markdown
Member Author

@MatthewCroughan

Copy link
Copy Markdown

you already do :D https://github.com/MatthewCroughan/nixcfg/blob/c7aa20d3f566ca97e5447a65a3058c5502500a31/flake.nix#L19

I'd never use it to generate sets or outputs though. I'm using it for a flake-utils-plus feature. I should get rid of that and slim my config down. Less repos to trust and rely upon existing. Code can still go missing on the internet, even if flakes let us pull in as much of it as we want. At least with Nixpkgs we have tarballs.nixos.org which lets us get around the instability of the internet. A flake with more than a few inputs is pretty scary, when you don't have something like tarballs.nixos.org, if you think about it.

@zimbatm

zimbatm commented May 27, 2022

Copy link
Copy Markdown
Member Author

I don't understand your arguments. nixpkgs maintainers have already rejected it. What is your point?

If you don't want it included here it's fine, I will just close the PR.

@zimbatm zimbatm closed this May 27, 2022
@MatthewCroughan

Copy link
Copy Markdown

@zimbatm I'm fine with it being here. I have no comment on that. I'm just commenting on the state of flakes, dependencies, and people not thinking about the inputs they consume as something that can disappear from the internet with no backup.

@MatthewCroughan

MatthewCroughan commented May 27, 2022

Copy link
Copy Markdown

It's probably worth noting also that this is a function ripped directly from flake-compat, so it already exists there. So in a way you would be blurring the lines between flake-utils and flake-compat.

https://github.com/edolstra/flake-compat/blob/master/default.nix#L84

@MatthewCroughan

Copy link
Copy Markdown

All-in-all. Probably better to wait until flakes stabilize, or support NixOS/rfcs#82 don't you think?

@zimbatm

zimbatm commented May 27, 2022

Copy link
Copy Markdown
Member Author

I don't need it so I don't care. I like the idea of making flake-compat a flake itself :)

@zimbatm

zimbatm commented May 27, 2022

Copy link
Copy Markdown
Member Author

And yes, depending on a bunch of third-party repos is always risky. Golang has a public proxy that keeps a cache of fetched projects, maybe we could do the same: https://go.dev/ref/mod#goproxy-protocol

@MatthewCroughan

Copy link
Copy Markdown

That sounds like a great idea. I would love to see an example of how to setup your own version of tarballs.nixos.org, or something like the public golang proxy.

@zimbatm

zimbatm commented May 30, 2022

Copy link
Copy Markdown
Member Author

There is always the good old:

nix flake archive --json \  | jq -r '.path,(.inputs|to_entries[].value.path)' \  | cachix push $cache_name

It would be cool if there was a reverse proxy that would automatically upload those to the cache.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants