lix-project/lix

Fork 31

Flake input.urls (plural) #459

New issue

Closed

opened 2024-08-04 04:37:24 +00:00 by toastal · 6 comments

toastal commented

2024-08-04 04:37:24 +00:00

See #444 (comment)

I want to have mirrors for inputs so I don’t have to rely on a single service being up (unlike input.url which allows just one mirror). Not only does this make your system more resilient, but it promotes others to put out multiple mirrors to their software (maybe even outside of proprietary code forges!).

Describe the solution you'd like

Like how many fetchers like fetchzip have url & urls, allow Flake inputs to support a list of URLs as mirrors. Whether or not these are raced, downloaded in parallel as mirrors, or fallbacks for a downed server, I do not have a strong feeling towards.

Describe alternatives you've considered

Being okay that pointing to my self-hosted code is more likely to be down than using a bigger platform with non-amateur-sysadmin being the singular source
Being okay using a bigger platform’s bandwidth even if they are actively looking for donations to support server costs being the singular source
Not having any sort of backup mirror at all despite the downsides this brings
Not using Flakes to manage dependencies. …But all of the alternative are still currently worse with management system not supporting mirrors, or worse only supporting Git (or worse still, only supporting/promoting Microsoft GitHub). Manually managing your dependencies is also a pretty bad experience.

## Is your feature request related to a problem? Please describe. See https://git.lix.systems/lix-project/lix/issues/444#issuecomment-5440 I want to have mirrors for inputs so I don’t have to rely on a single service being up (unlike `input.url` which allows just one mirror). Not only does this make your system more resilient, but it promotes others to put out multiple mirrors to their software (maybe even outside of proprietary code forges!). ## Describe the solution you'd like Like how many fetchers like `fetchzip` have `url` & `urls`, allow Flake inputs to support a list of URLs as mirrors. Whether or not these are raced, downloaded in parallel as mirrors, or fallbacks for a downed server, I do not have a strong feeling towards. ## Describe alternatives you've considered * Being okay that pointing to my self-hosted code is more likely to be down than using a bigger platform with non-amateur-sysadmin being the singular source * Being okay using a bigger platform’s bandwidth even if they are actively looking for donations to support server costs being the singular source * Not having any sort of backup mirror at all despite the downsides this brings * Not using Flakes to manage dependencies. …But all of the alternative are still currently worse with management system not supporting mirrors, or worse only supporting Git (or worse still, only supporting/promoting Microsoft GitHub). Manually managing your dependencies is also a pretty bad experience.

👍 1

jade added the

Area/flakes

labels 2024-08-07 06:02:21 +00:00

ifreilicht commented

2024-08-11 19:48:04 +00:00

Member

This would be an very cool feature! The main issue I see is that this will break compatibility with all other nix implementations, even the current version of lix itself:

$ nix --version
nix (Lix, like Nix) 2.90.0
$ nix flake show
warning: Git tree '/Users/feuh/repos/flakey-profile-list' is dirty
error:
       … while evaluating flake attribute 'urls'
         at /nix/store/dxbdv6qid09vkd51lk0hi49j4yv472v6-source/flake.nix:16:7:
           15|       url = "github:lf-/flakey-profile";
           16|       urls = [ "other URL" "secondary mirror" ];
             |       ^
           17|     };

       error: flake input attribute 'urls' is a thunk while a string, Boolean, or integer is expected

There is also currently no versioning for flakes like there is for profile manifests.

So any flake using it would probably not be usable by most people.

This would be an very cool feature! The main issue I see is that this will break compatibility with all other nix implementations, even the current version of lix itself: ``` $ nix --version nix (Lix, like Nix) 2.90.0 $ nix flake show warning: Git tree '/Users/feuh/repos/flakey-profile-list' is dirty error: … while evaluating flake attribute 'urls' at /nix/store/dxbdv6qid09vkd51lk0hi49j4yv472v6-source/flake.nix:16:7: 15| url = "github:lf-/flakey-profile"; 16| urls = [ "other URL" "secondary mirror" ]; | ^ 17| }; error: flake input attribute 'urls' is a thunk while a string, Boolean, or integer is expected ``` There is also currently no versioning for flakes like there is for profile manifests. So any flake using it would probably not be usable by most people.

toastal commented

2024-08-13 08:24:54 +00:00

Author

@ifreilicht My perception could be wrong, but isn’t part of the hope for Lix to ‘fix’ Flakes since upstream refuses to actually touch Flake stuff? I would love to report this upstream instead, but I am afraid it would never get looked at (& I hate using MS GitHub). I feel strongly that this was a major misstep in Flake design as it was definitely accounted for in the base fetchers. Personally I wouldn’t mind making my project ‘Lix only’ if that meant I could properly have mirrors. The realest shame here, as pointed out, is that this straight-up breaks to add additional keys as invalid rather than ignoring unknown attrset keys for alternative implementations to actually use. Maybe it would at least be possible to get NixCpp to be less strict in this specific area if they don’t want to improve the UX. Might there also be the opposite effect where if a feature is good & popular in Lix that it would put pressure on Nix to adopt it as well? (This conversation is getting pretty out of scope for the specific bug, but I don’t quite understand the process).

toastal commented

2024-08-13 08:37:33 +00:00

Author

Ah ha. This time using different keywords I did find the Nix issue https://github.com/NixOS/nix/issues/7007 on the NixCpp MS GitHub forge. It was opened in 2022 & has seen no action or response (probably since it is Flakes-related).

Ah ha. This time using different keywords I _did_ find the Nix issue <https://github.com/NixOS/nix/issues/7007> on the NixCpp MS GitHub forge. It was opened in 2022 & has seen no action or response (probably since it is Flakes-related).

ifreilicht commented

2024-08-13 08:49:31 +00:00

Member

My perception could be wrong, but isn’t part of the hope for Lix to ‘fix’ Flakes since upstream refuses to actually touch Flake stuff?

Well, kinda, but not necessarily by changing the basic structure of flakes. From the wiki (Why Lix? > Views on Flakes):

The Lix project acknowledges that flakes are the way that the majority of people use Nix today, and does not intend to remove support for them. However, as part of our overall focus on stability and dependability, some features of Flakes will be changed to be stricter.

Flakes are not the only way to write Nix language code in Lix, and we intend to provide a good experience to flakes users, while also improving the experience for those not using flakes, by evolving a compatible but more flexible flake-like abstraction in the periphery of the Lix system.

I don't know if that's still the current position, though, I'm not deeply immersed in the community.

> My perception could be wrong, but isn’t part of the hope for Lix to ‘fix’ Flakes since upstream refuses to actually touch Flake stuff? Well, kinda, but not necessarily by changing the basic structure of flakes. [From the wiki (Why Lix? > Views on Flakes)](https://wiki.lix.systems/books/lix-contributors/page/why-lix#bkmrk-views-on-flakes): > The Lix project acknowledges that flakes are the way that the majority of people use Nix today, and does not intend to remove support for them. However, as part of our overall focus on stability and dependability, **some features of Flakes will be changed to be stricter.** > > Flakes are not the only way to write Nix language code in Lix, and we intend to provide a good experience to flakes users, while also improving the experience for those not using flakes, by **evolving a compatible but more flexible flake-like abstraction in the periphery of the Lix system**. I don't know if that's still the current position, though, I'm not deeply immersed in the community.

👍 1

jade commented

2024-08-18 19:55:25 +00:00

Owner

Yes, I believe that is still the current position. Flakes, to me personally, are a constant liability and drain on resources but we absolutely must support them, and making them incompatible sounds like no end of pain.

Making things stricter by contrast will not break other implementations.

Yes, I believe that is still the current position. Flakes, to me personally, are a constant liability and drain on resources but we absolutely must support them, and making them *incompatible* sounds like no end of pain. Making things stricter by contrast will not break other implementations.

ifreilicht commented

2024-08-26 22:59:45 +00:00

Member

Ok, then I think this can be closed as won't fix.