opam lint and filters

[Drup]

This piece of opam file is passed by opam lint

messages: [
  "To build and install the graphical front-end glilis, you should install cairo2 lablgtk and cmdliner"
    {!cairo2 | !lablgtk | !cmdliner}
]

but gives the following error on install:

[ERROR] cairo2 is not a valid variable.
[WARNING] Invalid variable cairo2 in filter
[ERROR] 'cairo2' has type string, but a env element of type bool was expected.
Fatal error:
OpamFilter.Filter_type_error

[Drup]

Actually, and as we can see in #1802, opam lint could do much more to check filters (and it would be a good thing for people like me).

[AltGr]

Not really lint related but 1.2.1 has a clear definition of the semantics of filters, the conversions that may take place, and how it behaves with undefined values. It's documented here (see also the Variables section)

[Drup]

Kinda bumped on this one again: I tried to write { ocamlgraph >= "1.8.6" } as a filter. Not only opam lint accepted it but opam too, without error. The correct thing is of course to use ocamlgraph:version ...

[AltGr]

The issue is that we don't have a comprehensive list of variables, esp. not at the lint level ; variable resolution is defined at the state level, and, for example, new global variables can be added dynamically in ~/.opam/4.02.1/config/global-config.config (Actually that file currently only contains information that we can already infer, and we could do without it; but that's a different matter)

[Drup]

I understand the need to be extensible and all that, but is anybody actually using this feature of opam ? Can't opam lint warn on variables that have a good chance of being wrong ? There is a set of well known variables and then the packages, but the raw name of the package is rarely the variable you want to use (it's often package:something) and anyway, you can use the current universe + name of the package being defined as a quite good approximation.

[ghost]

I got hit twice this week by such a mistake. Just bumping this thread, despite not having a solution to the problem.

[AltGr]

Related: ocaml-opam/Camelus#8
Time to start writing a module enforcing repository-specific rules...

[rjbou]

Is this issue still current? I don't think with new opam versions...