On czw, 2017-05-11 at 11:47 +0700, Alex Turbov wrote: > DEPEND=( doc? > || ( > ( > dev-python/sphinx[python_targets_python2_7] > # NOTE This packages provide extensions for Sphinx > dev-python/rst-linker[python_targets_python2_7] > dev-python/jaraco-packaging[python_targets_python2_7] > ) > ( > dev-python/sphinx[python_targets_python3_5] > dev-python/rst-linker[python_targets_python3_5] > dev-python/jaraco-packaging[python_targets_python3_5] > ) > ( > dev-python/sphinx[python_targets_python3_6] > dev-python/rst-linker[python_targets_python3_6] > dev-python/jaraco-packaging[python_targets_python3_6] > ) > ) > ) >
One more thing I've missed in my initial mail. The other problem with
this solution (alone) is that it doesn't enforce the implementation that
satisfied the dependency.
Let's take a simple example. You've built sphinx for 2.7+3.5 but rst-
linker and jaraco-packaging for 3.5 only. The dependency is satisfied
because the 3.5 branch matches. However, you have no rule to enforce
3.5, so sphinx could be actually called with 2.7 and fail.
This is a generic problem that was pretty much solved by python-any-r1.
I think we should be able to copy the most important pieces of the API
to python-r1 to achieve something similar, i.e. add python_gen_any_dep
to generate the depstrings and make python_setup aware of
python_check_deps(). Then the above would be written alike:
DEPEND="doc? ( $(python_gen_any_dep '
dev-python/sphinx[${PYTHON_USEDEP}]
dev-python/rst-linker[${PYTHON_USEDEP}]
dev-python/jaraco-packaging[${PYTHON_USEDEP}]
') )"
python_check_deps() {
has_version "dev-python/sphinx[${PYTHON_USEDEP}]" &&
has_version "dev-python/rst-linker[${PYTHON_USEDEP}]" &&
has_version "dev-python/jaraco-packaging[${PYTHON_USEDEP}]"
}
python_setup would verify which implementation has the dependencies
satisfied, and set it for the common code building docs.
However:
1. I think it would work. However, I can't be sure until I implement it,
and even then I might miss something.
2. It's a significant extension to the API, and kinda goes against
the goal of making the eclass simpler. However, it mostly fits what is
in python-any-r1 already, so at least it doesn't introduce a new API.
So I'd like others to chime in and let me know whether they consider
this a worthwhile addition before I start working on it.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
