Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Always try next substituter #2441

Closed
wants to merge 1 commit into from
Closed

Always try next substituter #2441

wants to merge 1 commit into from

Conversation

dasJ
Copy link
Member

@dasJ dasJ commented Sep 22, 2018

This is related to #1990.
The current behaviour is counter-intuitive and conflicts with the
documentation of --fallback which states that the option is used to
build derivations locally if they fail to download.

@dasJ
Always try next substituter
bf071a3 
This is related to #1990.
The current behaviour is counter-intuitive and conflicts with the
documentation of --fallback which states that the option is used to
build derivations locally if they fail to download.
@dasJ
Copy link
Member Author

dasJ commented Jun 27, 2019

@edolstra Any update on this? The current behaviour is kind of annoying.

@dasJ
Copy link
Member Author

dasJ commented Jul 1, 2019

@edolstra Ping again

@grahamc
Copy link
Member

grahamc commented Jul 1, 2019

This PR seems to gut the functionality of --fallback, as it seems to delete all the code where that option would do anything. Am I right about that?

@dasJ
Copy link
Member Author

dasJ commented Jul 1, 2019

Not sure if the option does nothing after that. From --help, this it what it's supposed to do:

       --fallback
           Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.

           The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. If the repository is down, the realisation of the derivation
           will fail. When this option is specified, Nix will build the derivation instead. Thus, installation from binaries falls back on installation from source. This option is not the default since it is generally not desirable
           for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).

And building != using the next cache IMO

@grahamc
Copy link
Member

grahamc commented Jul 1, 2019

Can you look in to answering this question a bit more conclusively, to ensure the expected behavior of this flag is retained.

@dasJ
Copy link
Member Author

dasJ commented Jul 1, 2019

It seems, it's used to return early. Otherwise, the code (my C++ isn't too good) seems to retry

@dasJ
Copy link
Member Author

dasJ commented Feb 5, 2020 •
edited

Getting rid of my fork

@dasJ dasJ closed this Feb 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@edolstra edolstra Awaiting requested review from edolstra

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@dasJ @grahamc