--offline still requires dns configuration about lychee HOT 15 CLOSED

So looking at the upstream issue, it seems like we can pass our own resolver in that case.
We could define our own dummy resolver, similar to
https://github.com/seanmonstar/reqwest/blob/e639bdc1264c266a84dae3bae3193e07cae6861b/src/dns/gai.rs#L9
and use that when --offline is set.
If someone wants to give this a shot, please add a comment or create a PR.

from lychee.

I've updated NixOS/nixpkgs#298665 to explain the use case a bit more.

from lychee.

However, when putting together a test for it, I wasn't able to reproduce the failure, and indeed the latest lychee in Nixpkgs seems to work fine in the Nix sandbox. I don't really know what changed, but I'm quite happy about it!

I can confirm this as well. Thanks roberth as well for the PR to nixpkgs!

from lychee.

It's not necessarily about wireless configuration, but requiring an /etc/resolv.conf to exist is a problem for me too.

It seems that this problem could be solved in the most general way as described in seanmonstar/reqwest#2046.

from lychee.

Thanks for creating the issue and also thanks for providing a swift pull request to upstream. Here's hoping that this will be merged soon.

from lychee.

Oh that read like I referenced a PR, but I didn't write one (yet?). I'm not productive in Rust yet, so I figured I'd wait for a response first.

from lychee.

Oh, sorry, I checked on my phone and it looked like a PR.

As a workaround, can you try to create a dummy /etc/resolv.conf?
Something like

nameserver 8.8.8.8
nameserver 8.8.4.4

from lychee.

@roberth, any update on this? The upstream issue on reqwest didn't seem to get much traction. Did you try the workaround above by any chance?

from lychee.

To clarify, if reqwest does not support it, there is little we can do here. It would always throw an error then.

from lychee.

I've taken a shot at defining a dummy resolver, but found out that the hyper::client::connect::dns::Name is not in a public module.
My solution to that problem was to try a different provided resolver, actually the "gai" or getaddrinfo one you linked, but to actually use it, and that worked.
However, when putting together a test for it, I wasn't able to reproduce the failure, and indeed the latest lychee in Nixpkgs seems to work fine in the Nix sandbox.
I don't really know what changed, but I'm quite happy about it!

Something I did notice is that it the config file, any typos or unsupported properties, such as offline, are silently ignored.
Now that's not the explanation, but it did make me question my sanity when switching to a config file.

from lychee.

Oh, okay. Thanks for the update.

Invalid configs should definitely not be silently ignored. Perhaps we should switch to https://github.com/bnjjj/twelf
We used it for another project, and it worked quite fine.

from lychee.

I'm adding a helper function in Nixpkgs to make this use case easier, as well as a test in Nixpkgs that can catch a regression of this use case when lychee gets updated there.

• NixOS/nixpkgs#298665

Should I add Nix integration to the features when that's done?

from lychee.

Interesting. I don't know much about Nixpkgs.
We already mention NixOS support in the installation section here.
Is Nix integration different from this?

from lychee.

It is a bit different, and a somewhat more advanced use case. It does make use of package, which was always defined in the Nixpkgs repository, but it doesn't install it to a user's profile or anything.

The goal of the testers.lycheeLinkCheck function is to use Nix as a build tool to manage both the building and checking of a static site. That's especially nice if you're already building the site in the Nix sandbox.

You could think of it as a generic CI integration, that's easy to run locally.

from lychee.

I see. Thanks for the explanation.
Perhaps we can mention it in the installation section or a separate section in the README.md somewhere, as it might not be strictly a feature of the CLI tool then?

from lychee.