Meson not setting wrap mode nodownload

[nanonyme]

Looks like this is the key to what results Meson under BuildStream to try to contact to Internet (and failing) instead of just immediately complaining wrap is missing. The parameter is --wrap-mode=nodownload

[gtristan]

This is an interesting class of bug.

Obviously we would prefer meson to behave in a --wrap-mode=nodownload manner in order to produce a more human readable failure, as this would communicate the problem more clearly to project authors.

However we cannot fix this without breaking cache keys.

The policy for changing cache keys is that it must be "buy in" so that cache keys don't change without explicit plugin configuration selected, but in this case it is annoying to have to buy into a behavior that should really be default.

What's more, I'm not sure that the meson plugin parsing additional configuration can modify %{meson-args} in an optional way without implicitly breaking cache keys (i.e. there would have to be some if statement inserted into the configure commands).

The only non-breaking way I can think of off the top of my head right now, is for downstream users to explicitly add --wrap-mode=nodownload to meson-global in the project.conf variables.

If meson wrap mode could be controlled with environment variables, we might be able to use that in conjunction with environment-nocache in order to set this up without affecting cache keys (although I haven't given this enough thought to be 100% confident that this would be correct).

[nanonyme]

Yeah, I guess we might need to have something like

variables:
   meson-wrap-mode: nodownload
   meson-args: |
     ....
     --wrap-mode=%{meson-wrap-mode}

to ensure that you can actually easily change the value. I don't see any way to do this without breaking cache keys.

[alatiera]

The only non-breaking way I can think of off the top of my head right now, is for downstream users to explicitly add --wrap-mode=nodownload to meson-global in the project.conf variables.

Heh, ended up doing stumbling on this before even finding this issue. FYI we have the following MR atm in GNOME:

https://gitlab.gnome.org/GNOME/gnome-build-meta/-/merge_requests/2784

to ensure that you can actually easily change the value.

Good call, I'd expect the last argument to be honored so it should be fine to put it in meson-global as is, but should double check that this will work.

[nanonyme]

Good call, I'd expect the last argument to be honored so it should be fine to put it in meson-global as is, but should double check that this will work.

If this works, it would be a lot simpler to set up. Less moving parts. Still, cache keys change. IMHO the bad thing about cache keys is not the fact that cache keys change but that they have to consistently change for everyone. This is the case for freedesktop-sdk and gnome who junction this repo but not necessarily to projects pip installing the package. It's not great if it's possible for multiple developers building same project to get different cache keys.