RFE: auxdep annotations in autobuild.yaml

[ermo]

To make it as easy as possible to port auxdeps to the actual moss-format recipes when that becomes an option, maybe it would be a good idea to use the same format for the solver/ignore format for autobuild, as that would then act as prototyping work for how to do it in moss-format?

Proposed format addition to autobuild.yaml:

solver:
  ignore:
  - git: { auxdep: "Used for including git ref in version info" }
  - doxygen: { auxdep: "docdep" }
  - python-nose: { auxdep: "checkdep" }

Then we can experiment with when to actually display the extra encoded information?

[ermo]

As a follow-up, the point about the format above is that it is similar enough to the existing format that it will be possible to be forward compatible by doing it like this for now:

solver:
  ignore:
  - git #: { auxdep: "Used for including git ref in version info" }
  - doxygen #: { auxdep: "docdep" }
  - python-nose #: { auxdep: "checkdep" }

[silkeh]

I'm not sure what your proposal is trying to achieve: is it adding the fact that is't an auxdep , or trying to expose the reason behind the auxdep?

For the former I'd prefer a boolean, and for the latter an actual comment, as those are more flexible.
For example:

solver:
  ignore:
  # Used for including git ref in version info
  - git:
      auxdep: true
  # Docdep
  - doxygen:
      auxdep: true
  # checkdep
  - python-nose:
      auxdep: true

With comments:

solver:
  ignore:
  # Used for including git ref in version info
  - git #: {auxdep: true}
  # Docdep
  - doxygen #: {auxdep: true}
  # checkdep
  - python-nose #: {auxdep: true}

Note that comments are available in most YAML parsers if desired.

[ermo]

@silkeh: I'm not sure what your proposal is trying to achieve: is it adding the fact that it's an auxdep , or trying to expose the reason behind the auxdep?

Both.

From what I remember when writing this, the idea is to use autobuild to develop an annotation syntax that can, at some point, be used directly in stone.yaml recipes, so we don't need to drop-in autobuild.yaml files everywhere. However, we figured that it would be better to first experiment with what "useful annotation syntax" looks like in an external file.

When used directly in the recipe, having the ability to "tag" deps with a reason for the tag could be useful for both packagers/maintainers and for showing the tags when wanting to introspect resolver decisions with higher-than-default verbosity.

If you have standardised tag keys (in this case auxdep), then you can search for these keys with a YAML parser and then look for specific predefined values for either functional or statistical purposes (e.g. "checkdep" or "docdep").

It is not out of the realm of possibility that you would want to be able to specify multiple tags if you discover that this is useful, hence the { key: "what/why" } format:

Example:

- somedep
  auxdep: "checkdep"
  option: "slow_tests"
  comment: "This increases build times tenfold. Do not enable the mentioned options unless you want the parent build to take slightly longer than forever."

This should be understood in the context of serpent's "up front" / "dry-run" informational paradigm, where you are told/shown in advance what a build will require and why, rather than having to endure a full build to understand the consequences of selection options.