Look up variables even if they refer to other packages

[Leonidas-from-XIV]

OpamPackageVar.resolve_switch only looks up variables that are in the current package (and not specifying ~package seems to make no difference), so add code to retrieve the name of the package from the variable, retrieve the package from the installed packages and look up the variable in that package.

This PR:

1. Fixes the problem of not resolving variables that refer to other packages
2. Silences the warning about unresolved variables if the variable refers to a package that is not installed.
3. Keeps the warning if the variable is not referring to a package and undefined OR the package is installed and is missing the definition.

Closes #45.

[tmattio]

Hi! @rjbou pinging you since you're assigned as a reviewer - do you know when you'd have some time to review this or if anyone else would have the bandwidth to have a look?

This is causing unwanted warnings in opam-monorepo: tarides/opam-monorepo#349

[rjbou]

I don't understand why this need to be done, opam functions already do this resolving. From what I see, the issue comes from

opam-0install-solver/lib/switch_context.ml

Lines 19 to 32 in b759d7c

	let env t pkg v =
	if List.mem v OpamPackageVar.predefined_depends_variables then None
	else (
	let r = OpamPackageVar.resolve_switch ~package:pkg t.st v in
	if r = None then OpamConsole.warning "Unknown variable %S" (OpamVariable.Full.to_string v);
	r
	)
	let filter_deps t pkg f =
	let test = OpamPackage.Name.Set.mem (OpamPackage.name pkg) t.test in
	f
	|> OpamFilter.partial_filter_formula (env t pkg)
	|> OpamFilter.filter_deps ~build:true ~post:true ~test ~doc:false ~dev:false ~default:false

From what i understand, OpamPackageVar.resolve_switch is given as argument the package that is looked at, while it should take as argument a package for which it resolves the variable.
For that was, better us OpamPackageVar.resolve, that fully handle package variables, and is more specific to filtering.

[Leonidas-from-XIV]

@rjbou Thanks for your input.

If I look up the documentation of OpamPackageVar.resolve_switch I get

Resolves global variables within the context of a switch. If a package is specified, "name" and "version" as taken to exclusively resolve to the current package name and version.

Hence I would expect that it would also resolve other packages that are in the switch, but specifying ~package or not didn't seem to make a difference. My impression was that it would look up the values and if I specify ~package it would filter the results to only look up that particular package.

On the other hand, OpamPackageVar.resolve states

Resolves filter variables, including global, switch and package variables ; a map of locally defined variables can be supplied, as well as the opam file of origin, which is used to resolve self-references (implicit ["%{bin}%"] or explicit ["%{_:bin}%"]

Which makes me a bit wary to change, because I don't want global variables to factor into this.

It is well possible that I am using that API wrong, but we began seeing errors in #45 and my hunch of just removing ~package in the original source code didn't help to resolve the variable.

[talex5]

So, if I understand correctly (from ocaml/opam-repository#23736), the warning comes when a package refers to another package's variables in the conflicts field, which shouldn't be done. So this isn't a problem, and opam-0install-solver is correct to warn about it?

[Leonidas-from-XIV]

Yes, I think that's a correct reading of the issue. Closing the PR as the issue was solved on the opam-repository side.