:param resolution: Currently pinned candidate, or ``None``.

        :param candidates: A list of possible candidates.

        :param information: A list of requirement information.

        Each ``information`` instance is a named tuple with two entries:

          * ``requirement`` specifies a requirement contributing to
            the current candidate list

          * ``parent`` specifies the candidate that provides
            (dependend on) the requirement, or `None`
            to indicate a root requirement.

        resolvelib >=0.7.0, < 0.8.0

        :param identifier: The value returned by ``identify()``.

        :param resolutions: Mapping of identifier, candidate pairs.

        :param candidates: Possible candidates for the identifer.
            Mapping of identifier, list of candidate pairs.

        :param information: Requirement information of each package.
            Mapping of identifier, list of named tuple pairs.
            The named tuples have the entries ``requirement`` and ``parent``.

        resolvelib >=0.8.0, <= 1.0.1

        :param identifier: The value returned by ``identify()``.

        :param resolutions: Mapping of identifier, candidate pairs.

        :param candidates: Possible candidates for the identifer.
            Mapping of identifier, list of candidate pairs.

        :param information: Requirement information of each package.
            Mapping of identifier, list of named tuple pairs.
            The named tuples have the entries ``requirement`` and ``parent``.

        :param backtrack_causes: Sequence of requirement information that were
            the requirements that caused the resolver to most recently backtrack.

        The preference could depend on a various of issues, including
        (not necessarily in this order):

          * Is this package pinned in the current resolution result?

          * How relaxed is the requirement? Stricter ones should
            probably be worked on first? (I don't know, actually.)

          * How many possibilities are there to satisfy this
            requirement? Those with few left should likely be worked on
            first, I guess?

          * Are there any known conflicts for this requirement?
            We should probably work on those with the most
            known conflicts.

        A sortable value should be returned (this will be used as the
        `key` parameter of the built-in sorting function). The smaller
        the value is, the more preferred this requirement is (i.e. the
        sorting function is called with ``reverse=False``).
        ©