OS-dependent dependencies are recently coming up again, and this may be useful.

Currently, package definitions resolve variables (in so-called "filters") in two different scopes:

the concrete scope, available on package actions (build, installation, removal), with access to all variables on the set of installed packages.
the global scope, which is limited to non-package variables, and can be used before any scenario is computed. Well-defined self-references like %{_:name}% and %{_:version}% could be added without problem.

The latter is currently only used to compute the available: field, which filters the packages available before calling the solver. There would be no technical problems in allowing filters, with the global scope, on dependencies.

Extending the syntax in a reasonable way seems to be the biggest challenge here. We already have:

depends: [ "foo" { build & test & >= "1.2" & < "2.0" } ]

The build and test here are already an extension, and they need to be leading. We could actually generalise them (defining them as variables in this scope) and put a real "filter" at this point. But mixing in the same sequence "filter" terms and "version-formula" terms could be a bit misleading, if at all possible syntactically.

This would mean parsing dependencies to a single package to a (Filter of filter | Version_constraint of version_constraint) formula, and implement the first pass as resolving all filters and dropping constraints ANDed with a filter that evaluated to false — dropping the dependency if it reduces to Empty.

Allow variables in version constraints #1993

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions